Re: Bugfix for nanopi A64 dts

[André Przywara]

On 15/04/2021 07:02, Dietmar Kling wrote:
> Hi Guys,

Hi Dietmar,
  
> I have created a branch on github regarding two bugfixes which allow my 5 
> nanpoi a64 to connect to network again and also again use the second usb 
> port, when booting, when using the latest (v2021.04) u-boot.

Thanks for sharing this.
Please include the sunxi maintainers in your email, for improved
response time.
  
> https://github.com/DirkTheDaring/u-boot/tree/bugfix/nanopi-a64
>  
> The patch is attached to this text email.
> 
> Please include into u-boot official.
> 
> Kind Regards
> Dietmar

Please note that patches need your Signed-off-by:, to be eligible for
inclusion.

In general we don't take DT patches straight to U-Boot, they need to go
via the kernel tree first, then get synced back from time to time.
I just sent an update for all A64s, that should fix your network problem
already.

For the USB part: The sunxi Wiki is a bit controversial on this topic
(talking about a hub at some point), so can you clarify the USB
situation on the board?
Is controller 0 connected to the micro-USB socket, and the two type-A
receptables are connected via a hub?
Or is it like the Pine64: the two type-A receptables are connected to
controller 0 and 1, and the micro-USB is just for power?

If it is the latter, I wonder how this patch works for you? I need
another U-Boot patch [1] (which I want to send out shortly) to actually
enable this port 0 as a host port, and also rely on a DT change (now
merged in mainline Linux).

Cheers,
Andre

> 
> diff --git a/arch/arm/dts/sun50i-a64-nanopi-a64.dts 
> b/arch/arm/dts/sun50i-a64-nanopi-a64.dts
> index e58db8a6ca..a5c78bdb81 100644
> --- a/arch/arm/dts/sun50i-a64-nanopi-a64.dts
> +++ b/arch/arm/dts/sun50i-a64-nanopi-a64.dts
> @@ -80,7 +80,7 @@
>   {
>         pinctrl-names = "default";
>         pinctrl-0 = <_pins>;
> -       phy-mode = "rgmii";
> +       phy-mode = "rgmii-id";
>         phy-handle = <_rgmii_phy>;
>         phy-supply = <_dcdc1>;
>         status = "okay";
> @@ -258,6 +258,11 @@
>         status = "okay";
>  };
> +_otg {
> +       dr_mode = "host";
> +       status = "okay";
> +};
> +
>   {
>         status = "okay";
>  };
>  
>  
>  
> 

Re: [PATCH 1/1] pinephone_defconfig: lower DRAM clock to 528

[André Przywara]

On 22/02/2021 22:11, Bob wrote:

Hi Bob,

> Lower DRAM clock speed to the official speed for the pinephone design: 528

Can you elaborate why this is necessary? Are there reports with the
existing data rate causing problems?

Please keep in mind that the whole DRAM timings we use do not confirm to
any JEDEC standards, mostly the parameters are derived from some
Allwinner provided data. Since the clock frequency is connected to the
timing parameters (many values are defined in terms of number of
cycles), just lowering the frequency can have any kind of effects.

> Signed-off-by: Bobby The Builder 

Since this is a legal statement, I am afraid it has to carry your real name.

Cheers,
Andre

> ---
>  configs/pinephone_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> index d8ee930a69..702e2bdc14 100644
> --- a/configs/pinephone_defconfig
> +++ b/configs/pinephone_defconfig
> @@ -4,7 +4,7 @@ CONFIG_SPL=y
>  CONFIG_PINEPHONE_LEDS=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> -CONFIG_DRAM_CLK=552
> +CONFIG_DRAM_CLK=528
>  CONFIG_DRAM_ZQ=3881949
>  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>  CONFIG_PINEPHONE_DT_SELECTION=y

Re: [PATCH] nvme: add cache flush in get/set_features

[André Przywara]

On 26/02/2021 14:13, Neil Armstrong wrote:

Hi,

> On Amlogic G12A platforms, the NVME probe timeouts at get/set_feature(),
> adding a cache flush solves the timeout.

I am puzzled how this is supposed to work ...

> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/nvme/nvme.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 5d6331ad34..44c00a0309 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -487,11 +487,11 @@ int nvme_get_features(struct nvme_dev *dev, unsigned 
> fid, unsigned nsid,
>   c.features.nsid = cpu_to_le32(nsid);
>   c.features.prp1 = cpu_to_le64(dma_addr);
>   c.features.fid = cpu_to_le32(fid);
> -
>   /*
> -  * TODO: add cache invalidate operation when the size of
> +  * TODO: add better cache invalidate operation when the size of
>* the DMA buffer is known
>*/
> + invalidate_dcache_all();

Why is this? Isn't it totally dangerous, because we kill all the
information in dirty cache lines? We have extra checks in place to
prevent invalidating extra cache lines, when invalidating a single
buffer, but this is blanketly killing all of the cache?

And just ignoring for a minute that cache operations by set/way are
mostly wrong anyway? They are just meant to initialise the cache after
power state changes.

But more importantly: I don't see a single user of nvme_get_features()
in the tree? So this would never be called?

>  
>   return nvme_submit_admin_cmd(dev, , result);
>  }
> @@ -508,9 +508,10 @@ int nvme_set_features(struct nvme_dev *dev, unsigned 
> fid, unsigned dword11,
>   c.features.dword11 = cpu_to_le32(dword11);
>  
>   /*
> -  * TODO: add cache flush operation when the size of
> +  * TODO: add better cache flush operation when the size of
>* the DMA buffer is known
>*/
> + invalidate_dcache_all();

Same comment as above, first part: Dangerous and mostly wrong.
Besides: the comment speaks of "flush", not invalidate. So would be
extra wrong.
Also: there is exactly one caller in the whole tree, in this very same
file. And this one is passing a dma_addr of 0, apparently because it
doesn't actually use any buffer, instead passes the single piece of
information (the queue count) in the dword11 field.

So how is this supposed to work?

And if this seems to fix something, how?

Cheers,
Andre

>  
>   return nvme_submit_admin_cmd(dev, , result);
>  }
> 

Re: [PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40

[André Przywara]

On 20/02/2021 12:14, Nicolas Boulenguez wrote:

Hi,

> From: Icenowy Zheng 
> 
> Previously we have known that R40 has a configuration register for its
> rank 1, which allows different configuration than rank 0. Reverse
> engineering of newest libdram of A64 from Allwinner shows that A64 has
> this register too. It's bit 0 (which enables dual rank in rank 0
> configuration register) means a dedicated rank size setup is used for
> rank 1.
> 
> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
> DRAM support necessary.
> 
> Add this support. As we have gained knowledge of asymmetric dual rank,
> we can now allow R40 dual rank memory setup to work too.

Icenowy just sent a new version, together with another patch. I will
review her version, so you can drop this one here.

Cheers,
Andre

> 
> Signed-off-by: Icenowy Zheng 
> ---
>  .../include/asm/arch-sunxi/dram_sunxi_dw.h|  11 +-
>  arch/arm/mach-sunxi/dram_sunxi_dw.c   | 100 +-
>  2 files changed, 84 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index a5a7ebde44..e843c14202 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>  #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
>  /* The eight data lines (DQn) plus DM, DQS and DQSN */
>  #define LINES_PER_BYTE_LANE  (BITS_PER_BYTE + 3)
> -struct dram_para {
> +
> +struct rank_para {
>   u16 page_size;
> - u8 bus_full_width;
> - u8 dual_rank;
>   u8 row_bits;
>   u8 bank_bits;
> +};
> +
> +struct dram_para {
> + u8 dual_rank;
> + u8 bus_full_width;
> + struct rank_para ranks[2];
>   const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>   const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>   const u8 ac_delays[31];
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 85e7a1874e..b679f92e70 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -346,18 +346,24 @@ static void mctl_set_cr(uint16_t socid, struct 
> dram_para *para)
>  #else
>  #error Unsupported DRAM type!
>  #endif
> -(para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +(para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
>  MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>  (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> -MCTL_CR_PAGE_SIZE(para->page_size) |
> -MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
> +MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>  
> - if (socid == SOCID_R40) {
> - if (para->dual_rank)
> - panic("Dual rank memory not supported\n");
> + if (socid == SOCID_A64 || socid == SOCID_R40) {
> + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> +(para->dual_rank ? MCTL_CR_DUAL_RANK : 
> MCTL_CR_SINGLE_RANK) |
> +MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[1].row_bits), 
> _com->cr_r1);
> + }
>  
> + if (socid == SOCID_R40) {
>   /* Mux pin to A15 address line for single rank memory. */
> - setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> + if (!para->dual_rank)
> + setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
>   }
>  }
>  
> @@ -581,35 +587,63 @@ static int mctl_channel_init(uint16_t socid, struct 
> dram_para *para)
>   return 0;
>  }
>  
> -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para 
> *para)
> +/*
> + * Test if memory at offset offset matches memory at a certain base
> + */
> +static bool mctl_mem_matches_base(u32 offset, ulong base)
> +{
> + /* Try to write different values to RAM at two addresses */
> + writel(0, base);
> + writel(0xaa55aa55, base + offset);
> + dsb();
> + /* Check if the same value is actually observed when reading back */
> + return readl(base) ==
> +readl(base + offset);
> +}
> +
> +static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para 
> *para, ulong base, struct rank_para *rank)
>  {
>   /* detect row address bits */
> - para->page_size = 512;
> - para->row_bits = 16;
> - para->bank_bits = 2;
> + rank->page_size = 512;
> + rank->row_bits = 16;
> + rank->bank_bits = 2;
>   mctl_set_cr(socid, para);
>  
> - for (para->row_bits = 11; para->row_bits < 

Re: [PATCH 2/4] pinephone_defconfig: reduce boot delay

[André Przywara]

On 20/02/2021 12:14, Nicolas Boulenguez wrote:
> From: Arnaud Ferraris 
> 
> On a cellular phone, the vast majority of users can be expected to
> have no serial console connected and prefer a short boot.

It's a bit tricky to break in with a delay of 0, but indeed most users
won't care, so looks fine to me.

But it's missing a Signed-off-by: line.

Cheers,
Andre

> ---
>  configs/pinephone_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> index 9967cddab9..9b51a7a100 100644
> --- a/configs/pinephone_defconfig
> +++ b/configs/pinephone_defconfig
> @@ -10,4 +10,5 @@
>  CONFIG_PINEPHONE_DT_SELECTION=y
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2"
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_BOOTDELAY=0
>  CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2"
> 

Re: [PATCH] sunxi-common: support loading compressed kernel images on ARMv8

[André Przywara]

On 20/02/2021 12:14, Nicolas Boulenguez wrote:

Hi,

> From: Arnaud Ferraris 

This looks OK on the first glance, but is missing a commit message and a
Signed-off-by:

Cheers,
Andre

> 
> ---
>  include/configs/sunxi-common.h | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 5b0bec0561..227284cd29 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -291,6 +291,8 @@ extern int soft_i2c_gpio_scl;
>   */
>  #define BOOTM_SIZE   __stringify(0xa00)
>  #define KERNEL_ADDR_R__stringify(SDRAM_OFFSET(008))
> +#define KERNEL_COMP_ADDR_R   __stringify(SDRAM_OFFSET(400))
> +#define KERNEL_COMP_SIZE __stringify(0x400)
>  #define FDT_ADDR_R   __stringify(SDRAM_OFFSET(FA0))
>  #define SCRIPT_ADDR_R__stringify(SDRAM_OFFSET(FC0))
>  #define PXEFILE_ADDR_R   __stringify(SDRAM_OFFSET(FD0))
> @@ -332,6 +334,18 @@ extern int soft_i2c_gpio_scl;
>   "pxefile_addr_r=" PXEFILE_ADDR_R "\0" \
>   "ramdisk_addr_r=" RAMDISK_ADDR_R "\0"
>  
> +#ifdef CONFIG_ARM64
> +
> +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS \
> + "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \
> + "kernel_comp_size=" KERNEL_COMP_SIZE "\0"
> +
> +#else
> +
> +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS ""
> +
> +#endif
> +
>  #define DFU_ALT_INFO_RAM \
>   "dfu_alt_info_ram=" \
>   "kernel ram " KERNEL_ADDR_R " 0x100;" \
> @@ -487,6 +501,7 @@ extern int soft_i2c_gpio_scl;
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   CONSOLE_ENV_SETTINGS \
>   MEM_LAYOUT_ENV_SETTINGS \
> + MEM_LAYOUT_ENV_EXTRA_SETTINGS \
>   DFU_ALT_INFO_RAM \
>   "fdtfile=" FDTFILE "\0" \
>   "console=ttyS0,115200\0" \
> 

Re: [PATCH 20/20] Enable led on boot to notify user of boot status

[André Przywara]

On 20/02/2021 12:14, Nicolas Boulenguez wrote:
> From: Marius Gripsgard 

Hi,

This is not really Pinephone specific, actually not even sunxi specific.
I see two better ways of solving this:

- We introduce some generic code to find "gpio-leds" subnodes in the DT,
which have a default-state = "on" property. This could be either added
to drivers/led/led_gpio.c, or in some higher level.

- We introduce a generic boot LED GPIO config symbol. Maybe there is
already something, that sounds like a generally useful feature? That
would have the advantage of being already enabled in the SPL (admittedly
a sunxi specific problem).

Any opinions?

Cheers,
Andre

> ---
>  arch/arm/mach-sunxi/Kconfig | 5 +
>  board/sunxi/board.c | 4 ++--
>  configs/pinephone_defconfig | 1 +
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 8421f3b685..2bfdf7738b 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1,5 +1,10 @@
>  if ARCH_SUNXI
>  
> +config PINEPHONE_LEDS
> + bool "Notify boot status via LEDs on PinePhone"
> + ---help---
> + LED boot notification.
> +
>  config SPL_LDSCRIPT
>   default "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" if !ARM64
>  
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index abd7e390b2..a117b89ba2 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -637,6 +638,12 @@ void sunxi_board_init(void)
>  {
>   int power_failed = 0;
>  
> +#ifdef CONFIG_PINEPHONE_LEDS
> + /* PD18:G PD19:R PD20:B */
> + gpio_request(SUNXI_GPD(18), "led:green");
> + gpio_direction_output(SUNXI_GPD(18), 1);
> +#endif
> +
>  #ifdef CONFIG_SY8106A_POWER
>   power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
>  #endif
> diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> index ff5da42ce0..9de6ab2316 100644
> --- a/configs/pinephone_defconfig
> +++ b/configs/pinephone_defconfig
> @@ -1,6 +21,7 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_SPL=y
> +CONFIG_PINEPHONE_LEDS=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>  CONFIG_DRAM_CLK=552
> 

Re: [PATCH] arm: dts: sun50i-a64-pinephone: fix random wifi mac address

[André Przywara]

On 20/02/2021 12:14, Nicolas Boulenguez wrote:
> From: Arnaud Ferraris 
> 
> The wi-fi mac-address was previously changing at every reboot.

This is already part of the kernel .dtsi, which we will sync anyway
(with the new merge window). So we can drop this specific patch.

Cheers,
Andre

> 
> ---
>  arch/arm/dts/sun50i-a64-pinephone.dtsi | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/dts/sun50i-a64-pinephone.dtsi 
> b/arch/arm/dts/sun50i-a64-pinephone.dtsi
> index 25150aba74..86d55e38d8 100644
> --- a/arch/arm/dts/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm/dts/sun50i-a64-pinephone.dtsi
> @@ -14,6 +14,7 @@
>  / {
>   aliases {
>   serial0 = 
> + ethernet0 = 
>   };
>  
>   backlight: backlight {
> @@ -49,6 +50,13 @@
>   };
>   };
>  
> + reg_vbat_wifi: vbat-wifi {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vbat-wifi";
> + };
> +
>   speaker_amp: audio-amplifier {
>   compatible = "simple-audio-amplifier";
>   enable-gpios = < 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */
> @@ -195,6 +203,20 @@
>   status = "okay";
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_vbat_wifi>;
> + vqmmc-supply = <_dldo4>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + rtl8723cs: wifi@1 {
> + reg = <1>;
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> 

Re: [PATCH] sunxi: board: Splitting CHIP defconfig for nand.

[André Przywara]

On 24/01/2021 16:19, Alexandre GRIVEAUX wrote:

Hi Alexandre,

(CCing: Kory, plus using Maxime's and Boris' newer emails)

> This patch split CHIP defconfig to add nand 4G and 8G support.
> 
> Some CONFIG was put at the end of defconfig to ease comparison between:
> - CHIP Pro
> - CHIP with Toshiba 4G
> - CHIP with Hynix 8G
> 
> Witch are essentialy the same board with differents nand and memory.
> 
> Values was taken from now defunct compagny script "chip-update-firmware.sh"

Mmh, I am puzzled how this is supposed to work? I thought that the NAND
in the non-Pro version was not supported (MLC?). So booting via USB was
the only option?
Has this changed?

Can someone confirm that this works?

Cheers,
Andre

> Signed-off-by: Alexandre GRIVEAUX 
> ---
>  ...CHIP_defconfig => CHIP_Hynix_8G_defconfig} | 21 +---
>  configs/CHIP_Toshiba_4G_defconfig | 32 +++
>  2 files changed, 49 insertions(+), 4 deletions(-)
>  rename configs/{CHIP_defconfig => CHIP_Hynix_8G_defconfig} (50%)
>  create mode 100644 configs/CHIP_Toshiba_4G_defconfig
> 
> diff --git a/configs/CHIP_defconfig b/configs/CHIP_Hynix_8G_defconfig
> similarity index 50%
> rename from configs/CHIP_defconfig
> rename to configs/CHIP_Hynix_8G_defconfig
> index a70ee31d40..4d04a2798e 100644
> --- a/configs/CHIP_defconfig
> +++ b/configs/CHIP_Hynix_8G_defconfig
> @@ -4,16 +4,29 @@ CONFIG_SPL=y
>  CONFIG_MACH_SUN5I=y
>  CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
>  CONFIG_USB0_VBUS_PIN="PB10"
> -CONFIG_VIDEO_COMPOSITE=y
>  CONFIG_DEFAULT_DEVICE_TREE="sun5i-r8-chip"
>  CONFIG_SPL_I2C_SUPPORT=y
> -CONFIG_CMD_DFU=y
> -CONFIG_CMD_USB_MASS_STORAGE=y
> -CONFIG_DFU_RAM=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=sunxi-nand.0"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=sunxi-nand.0:256k(spl),256k(spl-backup),2m(uboot),2m(uboot-backup),-(UBI)"
> +CONFIG_ENV_IS_IN_UBI=y
> +CONFIG_ENV_UBI_PART="UBI"
> +CONFIG_ENV_UBI_VOLUME="uboot-env"
>  # CONFIG_MMC is not set
> +CONFIG_MTD=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_SYS_NAND_BLOCK_SIZE=0x40
> +CONFIG_SYS_NAND_PAGE_SIZE=0x4000
> +CONFIG_SYS_NAND_OOBSIZE=0x680
>  CONFIG_AXP_ALDO3_VOLT=3300
>  CONFIG_AXP_ALDO4_VOLT=3300
>  CONFIG_CONS_INDEX=2
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_FUNCTION_MASS_STORAGE=y
> +CONFIG_VIDEO_COMPOSITE=y
> +CONFIG_CMD_DFU=y
> +CONFIG_CMD_USB_MASS_STORAGE=y
> +CONFIG_DFU_RAM=y
> diff --git a/configs/CHIP_Toshiba_4G_defconfig 
> b/configs/CHIP_Toshiba_4G_defconfig
> new file mode 100644
> index 00..bbc6cd9744
> --- /dev/null
> +++ b/configs/CHIP_Toshiba_4G_defconfig
> @@ -0,0 +1,32 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN5I=y
> +CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
> +CONFIG_USB0_VBUS_PIN="PB10"
> +CONFIG_DEFAULT_DEVICE_TREE="sun5i-r8-chip"
> +CONFIG_SPL_I2C_SUPPORT=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nand0=sunxi-nand.0"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=sunxi-nand.0:256k(spl),256k(spl-backup),2m(uboot),2m(uboot-backup),-(UBI)"
> +CONFIG_ENV_IS_IN_UBI=y
> +CONFIG_ENV_UBI_PART="UBI"
> +CONFIG_ENV_UBI_VOLUME="uboot-env"
> +# CONFIG_MMC is not set
> +CONFIG_MTD=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_SYS_NAND_BLOCK_SIZE=0x40
> +CONFIG_SYS_NAND_PAGE_SIZE=0x4000
> +CONFIG_SYS_NAND_OOBSIZE=0x500
> +CONFIG_AXP_ALDO3_VOLT=3300
> +CONFIG_AXP_ALDO4_VOLT=3300
> +CONFIG_CONS_INDEX=2
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_FUNCTION_MASS_STORAGE=y
> +CONFIG_VIDEO_COMPOSITE=y
> +CONFIG_CMD_DFU=y
> +CONFIG_CMD_USB_MASS_STORAGE=y
> +CONFIG_DFU_RAM=y
> 

Re: [PATCH 05/16] arm: Remove highbank board

[André Przywara]

On 10/02/2021 02:42, Tom Rini wrote:

Hi Tom,

> This board relies on using CONFIG_LIBATA but does not enable CONFIG_AHCI.  The
> deadline for this conversion was the v2019.07 release.  The use of CONFIG_AHCI
> requires CONFIG_DM.  The deadline for this conversion was v2020.01.  Remove
> this board.

So I made a series a few months ago to bring highbank up to speed, it
converts everything over to DM, also starts using the DT provided by the
board for its own purposes.
I was facing one issue with SATA though, which made me drop the ball
there :-(
This is for the 2014.07 merge window, I guess? So if I manage to send
something before April, would you consider dropping this patch then?
Or do I need to start the series with a revert?

Cheers,
Andre

> 
> Cc: Rob Herring 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/Kconfig|   7 --
>  arch/arm/Makefile   |   1 -
>  arch/arm/mach-highbank/Kconfig  |  12 --
>  arch/arm/mach-highbank/Makefile |   6 -
>  arch/arm/mach-highbank/timer.c  |  34 --
>  board/highbank/MAINTAINERS  |   6 -
>  board/highbank/Makefile |   6 -
>  board/highbank/ahci.c   | 207 
>  board/highbank/highbank.c   | 148 ---
>  configs/highbank_defconfig  |  28 -
>  include/configs/highbank.h  |  60 -
>  11 files changed, 515 deletions(-)
>  delete mode 100644 arch/arm/mach-highbank/Kconfig
>  delete mode 100644 arch/arm/mach-highbank/Makefile
>  delete mode 100644 arch/arm/mach-highbank/timer.c
>  delete mode 100644 board/highbank/MAINTAINERS
>  delete mode 100644 board/highbank/Makefile
>  delete mode 100644 board/highbank/ahci.c
>  delete mode 100644 board/highbank/highbank.c
>  delete mode 100644 configs/highbank_defconfig
>  delete mode 100644 include/configs/highbank.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 95557d6ed6bd..6fa69d39be5b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -750,11 +750,6 @@ config ARCH_S5PC1XX
>   select DM_SERIAL
>   imply CMD_DM
>  
> -config ARCH_HIGHBANK
> - bool "Calxeda Highbank"
> - select CPU_V7A
> - select PL011_SERIAL
> -
>  config ARCH_INTEGRATOR
>   bool "ARM Ltd. Integrator family"
>   select DM
> @@ -1873,8 +1868,6 @@ source "arch/arm/mach-davinci/Kconfig"
>  
>  source "arch/arm/mach-exynos/Kconfig"
>  
> -source "arch/arm/mach-highbank/Kconfig"
> -
>  source "arch/arm/mach-integrator/Kconfig"
>  
>  source "arch/arm/mach-ipq40xx/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 28b523b37c70..e1d266c3a4d8 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -57,7 +57,6 @@ machine-$(CONFIG_ARCH_BCM283X)  += bcm283x
>  machine-$(CONFIG_ARCH_BCMSTB)+= bcmstb
>  machine-$(CONFIG_ARCH_DAVINCI)   += davinci
>  machine-$(CONFIG_ARCH_EXYNOS)+= exynos
> -machine-$(CONFIG_ARCH_HIGHBANK)  += highbank
>  machine-$(CONFIG_ARCH_IPQ40XX)   += ipq40xx
>  machine-$(CONFIG_ARCH_K3)+= k3
>  machine-$(CONFIG_ARCH_KEYSTONE)  += keystone
> diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
> deleted file mode 100644
> index 0e73c0414293..
> --- a/arch/arm/mach-highbank/Kconfig
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -if ARCH_HIGHBANK
> -
> -config SYS_BOARD
> - default "highbank"
> -
> -config SYS_SOC
> - default "highbank"
> -
> -config SYS_CONFIG_NAME
> - default "highbank"
> -
> -endif
> diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile
> deleted file mode 100644
> index 029e266bedce..
> --- a/arch/arm/mach-highbank/Makefile
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# (C) Copyright 2000-2006
> -# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> -
> -obj-y:= timer.o
> diff --git a/arch/arm/mach-highbank/timer.c b/arch/arm/mach-highbank/timer.c
> deleted file mode 100644
> index 2423a0e37855..
> --- a/arch/arm/mach-highbank/timer.c
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright 2010-2011 Calxeda, Inc.
> - *
> - * Based on arm926ejs/mx27/timer.c
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#undef SYSTIMER_BASE
> -#define SYSTIMER_BASE0xFFF34000  /* Timer 0 and 1 base   
> */
> -
> -static struct systimer *systimer_base = (struct systimer *)SYSTIMER_BASE;
> -
> -/*
> - * Start the timer
> - */
> -int timer_init(void)
> -{
> - /*
> -  * Setup timer0
> -  */
> - writel(0, _base->timer0control);
> - writel(SYSTIMER_RELOAD, _base->timer0load);
> - writel(SYSTIMER_RELOAD, _base->timer0value);
> - writel(SYSTIMER_EN | SYSTIMER_32BIT | SYSTIMER_PRESC_256,
> - _base->timer0control);
> -
> - return 0;
> -
> -}
> diff --git a/board/highbank/MAINTAINERS 

Re: sunxi/pinephone suggestions and fixes

[André Przywara]

On 17/02/2021 16:19, Nicolas Boulenguez wrote:

Hi Nicolas,

> Please consider the attached suggestions for the sunxi/pinephone
> platform.
> Among commits written for and by Mobian users, these ones may be of
> interest for all pinephone owners.
> Each header mentions the original motivation and author.

Please send this as a proper series, with each patch in a separate
email. That makes it possible to look at and discuss the individual patches.
git send-email should help you with that, it looks like the patches are
already in mbox format, so just enumerating them on the command line
should do the trick. Sending to yourself only first (--to 
--suppress-cc=all) helps to get this right ;-)

And please address maintainers directly, scripts/get_maintainer.pl
should give you some idea who to address (feel free to filter that list,
the output is sometimes quite verbose).

Cheers,
Andre

Re: [PATCH] sunxi: Use kconfig instead define CONFIG_I2C_EDID

[André Przywara]

On 16/02/2021 08:31, Игорь Юрасов wrote:

Hi,

> Signed-off-by: Igor Iurasov 

This will be superseded by the switch to DM_VIDEO:
https://patchwork.ozlabs.org/project/uboot/patch/20210205010748.2646-1-andre.przyw...@arm.com/

Cheers,
Andre

P.S. Please CC: maintainers directly, scripts/get_maintainer.pl tells
you who to send the mail to.

> ---
>  arch/arm/mach-sunxi/Kconfig| 1 +
>  include/configs/sunxi-common.h | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 0135575ca1..1ffdc3de1d 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -818,6 +818,7 @@ config VIDEO_SUNXI
>   depends on !SUN50I_GEN_H6
>   select VIDEO
>   imply VIDEO_DT_SIMPLEFB
> + imply I2C_EDID
>   default y
>   ---help---
>   Say Y here to add support for using a cfb console on the HDMI, LCD
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 000f386470..068aef2f5a 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -265,7 +265,6 @@ extern int soft_i2c_gpio_scl;
> 
>  #define CONFIG_VIDEO_LOGO
>  #define CONFIG_VIDEO_STD_TIMINGS
> -#define CONFIG_I2C_EDID
>  #define VIDEO_LINE_LEN (pGD->plnSizeX)
> 
>  /* allow both serial and cfb console. */
> 

Re: [PATCH] sunxi: don't define MACPWR and SATAPWR to empty strings

[André Przywara]

On 18/01/2021 00:18, Peter Robinson wrote:
> There's checks in board/sunxi/board.c if either MACPWR or SATAPWR are
> defined and they are defined by default to a empty string which means
> on vast majority of AllWinner boards when they're not required the
> code is still run and with SATAPWR we even get an unnecessary 500ms
> delay booting. So let's not define a default for these options so the
> code is only run for boards that need it.

Ouch, that's a good one!
Looks good to me, I will do some checks and testing to verify.

Actually it looks even worse, since we don't check the return value of
sunxi_name_to_gpio(), and gpio_direction_output() doesn't either. I
wonder how this didn't crash before ...

Plus I wonder if we can move those two pins to be handled by DT.

Anyway, first things first...
Thanks for the patch!

Cheers,
Andre

> 
> Signed-off-by: Peter Robinson 
> ---
>  arch/arm/mach-sunxi/Kconfig | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 49ef217f08..a566e10315 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -578,7 +578,6 @@ config OLD_SUNXI_KERNEL_COMPAT
>  
>  config MACPWR
>   string "MAC power pin"
> - default ""
>   help
> Set the pin used to power the MAC. This takes a string in the format
> understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
> @@ -969,7 +968,6 @@ endchoice
>  
>  config SATAPWR
>   string "SATA power pin"
> - default ""
>   help
> Set the pins used to power the SATA. This takes a string in the
> format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
> 

Re: [PATCH v3 5/6] mmc: actions: add MMC driver for Actions OWL S700/S900

[André Przywara]

On 16/01/2021 18:32, Amit Singh Tomar wrote:
> From: Amit Singh Tomar 

Hi,

> This commit adds support for MMC controllers found on Actions OWL
> SoC platform(S700/S900).
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v2:
> * Progammed read/write delays as suggested by
>   Jaehoon, its more readable now.
> * Updated commit message and source file to reflect
>   it supports S900 as well.
> * Updated SD_DMA_CHANNEL macro to include channel offset.
> * Checked the command response Error based on SDC STATU register
>   bits.
> * Replaced switch/case with if/else to correlate with MMC_RSP_Rx 
> bitmask
> values, as suggested by Andre.
> * Introduced clk_disable based on mmc->clk_disable flag.
> * Guarded the clk_set_rate under if statment to avoid reprogramming 
> the
>   rate.
> * Fetched the DRQ number from using args.args[0].
> Changes since previous version
> * Corrected block count to 512.
> * Changed the command timeout value to 30ms.
> * Used readl_poll_timeout.
> * Read DMA parameters from DT instead of hardcoding it.
> * Reduced number of arguments passed to own_dma_cofig.
> * Removed debug leftover.
> * Used mmc_of_parse().
> ---
>  drivers/mmc/Kconfig   |   7 +
>  drivers/mmc/Makefile  |   1 +
>  drivers/mmc/owl_mmc.c | 401 
> ++
>  3 files changed, 409 insertions(+)
>  create mode 100644 drivers/mmc/owl_mmc.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 14d7913..3478a4e 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -289,6 +289,13 @@ config MMC_MXC
>  
> If unsure, say N.
>  
> +config MMC_OWL
> + bool "Actions OWL Multimedia Card Interface support"
> + depends on ARCH_OWL && DM_MMC && BLK
> + help
> +   This selects the OWL SD/MMC host controller found on board
> +   based on Actions S700/S900 SoC.
> +
>  config MMC_MXS
>   bool "Freescale MXS Multimedia Card Interface support"
>   depends on MX23 || MX28 || MX6 || MX7
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 1c849cb..f270f6c 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)   += omap_hsmmc.o
>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>  obj-$(CONFIG_MMC_MXS)+= mxsmmc.o
>  obj-$(CONFIG_MMC_OCTEONTX)   += octeontx_hsmmc.o
> +obj-$(CONFIG_MMC_OWL)+= owl_mmc.o
>  obj-$(CONFIG_MMC_PCI)+= pci_mmc.o
>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
> diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
> new file mode 100644
> index 000..de52583
> --- /dev/null
> +++ b/drivers/mmc/owl_mmc.c
> @@ -0,0 +1,401 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Amit Singh Tomar 
> + *
> + * Driver for SD/MMC controller present on Actions Semi S700/S900 SoC, based
> + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
> + *
> + * Though, there is a bit (BSEL, BUS or DMA Special Channel Selection) that
> + * controls the data transfer from SDx_DAT register either using CPU AHB Bus
> + * or DMA channel, but seems like, it only works correctly using external DMA
> + * channel, and those special bits used in this driver is picked from vendor
> + * source exclusively for MMC/SD.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SDC registers
> + */
> +#define OWL_REG_SD_EN0x
> +#define OWL_REG_SD_CTL   0x0004
> +#define OWL_REG_SD_STATE 0x0008
> +#define OWL_REG_SD_CMD   0x000c
> +#define OWL_REG_SD_ARG   0x0010
> +#define OWL_REG_SD_RSPBUF0   0x0014
> +#define OWL_REG_SD_RSPBUF1   0x0018
> +#define OWL_REG_SD_RSPBUF2   0x001c
> +#define OWL_REG_SD_RSPBUF3   0x0020
> +#define OWL_REG_SD_RSPBUF4   0x0024
> +#define OWL_REG_SD_DAT   0x0028
> +#define OWL_REG_SD_BLK_SIZE  0x002c
> +#define OWL_REG_SD_BLK_NUM   0x0030
> +#define OWL_REG_SD_BUF_SIZE  0x0034
> +
> +/* SD_EN Bits */
> +#define OWL_SD_EN_RANE   BIT(31)
> +#define OWL_SD_EN_RESE   BIT(10)
> +#define OWL_SD_ENABLEBIT(7)
> +#define OWL_SD_EN_BSEL   BIT(6)
> +#define OWL_SD_EN_DATAWID(x) (((x) & 0x3) << 0)
> +#define OWL_SD_EN_DATAWID_MASK   0x03
> +
> +/* SD_CTL Bits */
> +#define OWL_SD_CTL_TOUTENBIT(31)
> +#define OWL_SD_CTL_DELAY_MSK GENMASK(23, 16)
> +#define OWL_SD_CTL_RDELAY(x) (((x) & 0xf) << 

Re: [PATCH] net: sun8i-emac: Allow all RGMII PHY modes

[André Przywara]

On 30/11/2020 17:23, Heinrich Schuchardt wrote:

Hi Joe,

> On 11/16/20 10:46 AM, Andre Przywara wrote:
>> So far all GBit users of the sun8i-emac driver were using the "rgmii"
>> PHY mode, even though this turns out to be mostly wrong. It just worked
>> because the PHY driver doesn't do the proper setup (yet).
>> In fact for most boards the "rgmii-id" or "rgmii-txid" PHY modes are the
>> correct ones.
>>
>> To allow the DTs to describe the phy-mode correctly, and to stay
>> compatible with Linux, at least allow those other RGMII modes in the
>> driver.
>>
>> This avoids breakage if mainline DTs will be synced with U-Boot.
>>
>> An almost identical patch (f1239d8aa84d) was merged into the Linux driver
>> and has been backported to stable kernels.
>>
>> Signed-off-by: Andre Przywara 

Are you going to take this through your tree?
Or are you OK with me merging this through u-boot-sunxi?
We depend on this for a DT update, which relies on those new PHY modes.

Cheers,
Andre

> 
> Hello Joe,
> 
> could we get this into v2021.01, please?
> 
> Acked-by: Heinrich Schuchardt 

Re: [PATCH 16/17] clk: sunxi: Add support for H616 clocks

[André Przywara]

On 03/01/2021 09:26, Jernej Skrabec wrote:
> This commit introduces DM H616 clock driver.
> 
> Signed-off-by: Jernej Skrabec 

Compared against the manual.

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  drivers/clk/sunxi/Kconfig|   7 ++
>  drivers/clk/sunxi/Makefile   |   1 +
>  drivers/clk/sunxi/clk_h616.c | 120 +++
>  3 files changed, 128 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk_h616.c
> 
> diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
> index 5ff101b99305..bf084fa7a84a 100644
> --- a/drivers/clk/sunxi/Kconfig
> +++ b/drivers/clk/sunxi/Kconfig
> @@ -79,6 +79,13 @@ config CLK_SUN50I_H6
> This enables common clock driver support for platforms based
> on Allwinner H6 SoC.
>  
> +config CLK_SUN50I_H616
> + bool "Clock driver for Allwinner H616"
> + default MACH_SUN50I_H616
> + help
> +   This enables common clock driver support for platforms based
> +   on Allwinner H616 SoC.
> +
>  config CLK_SUN50I_A64
>   bool "Clock driver for Allwinner A64"
>   default MACH_SUN50I
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 36fb2aeb56c5..0dfc0593fb1c 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
>  obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
>  obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
>  obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
> +obj-$(CONFIG_CLK_SUN50I_H616) += clk_h616.o
>  obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
> diff --git a/drivers/clk/sunxi/clk_h616.c b/drivers/clk/sunxi/clk_h616.c
> new file mode 100644
> index ..e2e3a5c78c95
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk_h616.c
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2021 Jernej Skrabec 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct ccu_clk_gate h616_gates[] = {
> + [CLK_BUS_MMC0]  = GATE(0x84c, BIT(0)),
> + [CLK_BUS_MMC1]  = GATE(0x84c, BIT(1)),
> + [CLK_BUS_MMC2]  = GATE(0x84c, BIT(2)),
> +
> + [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
> + [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
> + [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
> + [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
> + [CLK_BUS_UART4] = GATE(0x90c, BIT(4)),
> + [CLK_BUS_UART5] = GATE(0x90c, BIT(5)),
> +
> + [CLK_SPI0]  = GATE(0x940, BIT(31)),
> + [CLK_SPI1]  = GATE(0x944, BIT(31)),
> +
> + [CLK_BUS_SPI0]  = GATE(0x96c, BIT(0)),
> + [CLK_BUS_SPI1]  = GATE(0x96c, BIT(1)),
> +
> + [CLK_BUS_EMAC0] = GATE(0x97c, BIT(0)),
> + [CLK_BUS_EMAC1] = GATE(0x97c, BIT(1)),
> +
> + [CLK_USB_PHY0]  = GATE(0xa70, BIT(29)),
> + [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
> +
> + [CLK_USB_PHY1]  = GATE(0xa74, BIT(29)),
> + [CLK_USB_OHCI1] = GATE(0xa74, BIT(31)),
> +
> + [CLK_USB_PHY2]  = GATE(0xa78, BIT(29)),
> + [CLK_USB_OHCI2] = GATE(0xa78, BIT(31)),
> +
> + [CLK_USB_PHY3]  = GATE(0xa7c, BIT(29)),
> + [CLK_USB_OHCI3] = GATE(0xa7c, BIT(31)),
> +
> + [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
> + [CLK_BUS_OHCI1] = GATE(0xa8c, BIT(1)),
> + [CLK_BUS_OHCI2] = GATE(0xa8c, BIT(2)),
> + [CLK_BUS_OHCI3] = GATE(0xa8c, BIT(3)),
> + [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
> + [CLK_BUS_EHCI1] = GATE(0xa8c, BIT(5)),
> + [CLK_BUS_EHCI2] = GATE(0xa8c, BIT(6)),
> + [CLK_BUS_EHCI3] = GATE(0xa8c, BIT(7)),
> + [CLK_BUS_OTG]   = GATE(0xa8c, BIT(8)),
> +};
> +
> +static struct ccu_reset h616_resets[] = {
> + [RST_BUS_MMC0]  = RESET(0x84c, BIT(16)),
> + [RST_BUS_MMC1]  = RESET(0x84c, BIT(17)),
> + [RST_BUS_MMC2]  = RESET(0x84c, BIT(18)),
> +
> + [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
> + [RST_BUS_UART4] = RESET(0x90c, BIT(20)),
> + [RST_BUS_UART5] = RESET(0x90c, BIT(21)),
> +
> + [RST_BUS_SPI0]  = RESET(0x96c, BIT(16)),
> + [RST_BUS_SPI1]  = RESET(0x96c, BIT(17)),
> +
> + [RST_BUS_EMAC0] = RESET(0x97c, BIT(16)),
> + [RST_BUS_EMAC1] = RESET(0x97c, BIT(17)),
> +
> + [RST_USB_PHY0]  = RESET(0xa70, BIT(30)),
> +
> + [RST_USB_PHY1]  = RESET(0xa74, BIT(30)),
> +
> + [RST_USB_PHY2]  = RESET(0xa78, BIT(30)),
> +
> + [RST_USB_PHY3]  = RESET(0xa7c, BIT(30)),
> +
> + [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
> + [RST_BUS_OHCI1] = 

Re: [PATCH 15/17] sunxi: gpio: introduce compatible for H616

[André Przywara]

On 03/01/2021 09:26, Jernej Skrabec wrote:
> H616 pinctrl is no different configuration wise than others, so just add
> compatible for it.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  drivers/gpio/sunxi_gpio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index 02c3471b5684..1985ee5d2fc9 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -356,6 +356,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
>   ID("allwinner,sun9i-a80-pinctrl",   a_all),
>   ID("allwinner,sun50i-a64-pinctrl",  a_all),
>   ID("allwinner,sun50i-h6-pinctrl",   a_all),
> + ID("allwinner,sun50i-h616-pinctrl", a_all),
>   ID("allwinner,sun6i-a31-r-pinctrl", l_2),
>   ID("allwinner,sun8i-a23-r-pinctrl", l_1),
>   ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
> 

Re: [PATCH 03/17] mmc: sunxi: Replace H6 ifdefs with H6 gen macro

[André Przywara]

On 03/01/2021 09:26, Jernej Skrabec wrote:
> It turns out that several SoCs share same mmc configuration as H6. In
> order to lower ifdef clutter replace H6 specific macro with common one.
> 
> Signed-off-by: Jernej Skrabec 

Shame we need to do this, but the SPL requires this ifdef orgy.

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  arch/arm/include/asm/arch-sunxi/mmc.h |  2 +-
>  drivers/mmc/sunxi_mmc.c   | 12 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
> b/arch/arm/include/asm/arch-sunxi/mmc.h
> index f2deafddd202..340e25b04d2a 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -45,7 +45,7 @@ struct sunxi_mmc {
>   u32 chda;   /* 0x90 */
>   u32 cbda;   /* 0x94 */
>   u32 res2[26];
> -#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
> +#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
>   u32 res3[17];
>   u32 samp_dl;
>   u32 res4[46];
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 0e03b07ce555..3767a39277c1 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -122,7 +122,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
>   if (IS_ENABLED(CONFIG_MACH_SUN8I_A83T) && priv->mmc_no != 2)
>   new_mode = false;
>  
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN50I_H6)
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_SUN50I_GEN_H6)
>   calibrate = true;
>  #endif
>  
> @@ -133,7 +133,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
> unsigned int hz)
>  #ifdef CONFIG_MACH_SUN9I
>   pll = CCM_MMC_CTRL_PLL_PERIPH0;
>   pll_hz = clock_get_pll4_periph0();
> -#elif defined(CONFIG_MACH_SUN50I_H6)
> +#elif defined(CONFIG_SUN50I_GEN_H6)
>   pll = CCM_MMC_CTRL_PLL6X2;
>   pll_hz = clock_get_pll6() * 2;
>  #else
> @@ -249,7 +249,7 @@ static int mmc_config_clock(struct sunxi_mmc_priv *priv, 
> struct mmc *mmc)
>   rval &= ~SUNXI_MMC_CLK_DIVIDER_MASK;
>   writel(rval, >reg->clkcr);
>  
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN50I_H6)
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_SUN50I_GEN_H6)
>   /* A64 supports calibration of delays on MMC controller and we
>* have to set delay of zero before starting calibration.
>* Allwinner BSP driver sets a delay only in the case of
> @@ -530,7 +530,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>  
>   cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>   cfg->host_caps = MMC_MODE_4BIT;
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) || 
> defined(CONFIG_MACH_SUN50I_H6)
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) || 
> defined(CONFIG_SUN50I_GEN_H6)
>   if (sdc_no == 2)
>   cfg->host_caps = MMC_MODE_8BIT;
>  #endif
> @@ -545,7 +545,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>  
>   /* config ahb clock */
>   debug("init mmc %d clock and io\n", sdc_no);
> -#if !defined(CONFIG_MACH_SUN50I_H6)
> +#if !defined(CONFIG_SUN50I_GEN_H6)
>   setbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
>  
>  #ifdef CONFIG_SUNXI_GEN_SUN6I
> @@ -557,7 +557,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>   writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
>  SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
>  #endif
> -#else /* CONFIG_MACH_SUN50I_H6 */
> +#else /* CONFIG_SUN50I_GEN_H6 */
>   setbits_le32(>sd_gate_reset, 1 << sdc_no);
>   /* unassert reset */
>   setbits_le32(>sd_gate_reset, 1 << (RESET_SHIFT + sdc_no));
> 

Re: [linux-sunxi] [PATCH 02/17] sunxi: Introduce common symbol for H6 like SoCs

[André Przywara]

On 04/01/2021 18:28, Jernej Škrabec wrote:
> Dne ponedeljek, 04. januar 2021 ob 11:35:41 CET je André Przywara napisal(a):
>> On 03/01/2021 23:43, Samuel Holland wrote:
>>
>> Hi Jernej,
>>
>> thanks for that patch, that's a nice solution to avoid those long #ifdef
>> chains!
>>
>>> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
>>>> It turns out that there are at least 2 other SoCs which have basically
>>>> the same memory map, similar clocks and other features as H6. It's very
>>>> likely that we'll see more such SoCs in the future. In order to ease
>>>> porting to new SoCs and lower ifdef clutter, introduce common symbol for
>>>> them.
>>>>
>>>> Signed-off-by: Jernej Skrabec 
>>>> ---
>>>>
>>>>  arch/arm/include/asm/arch-sunxi/boot0.h |  2 +-
>>>>  arch/arm/include/asm/arch-sunxi/clock.h |  2 +-
>>>>  arch/arm/include/asm/arch-sunxi/cpu.h   |  2 +-
>>>>  arch/arm/include/asm/arch-sunxi/timer.h |  2 +-
>>>>  arch/arm/mach-sunxi/Kconfig | 21 +
>>>>  arch/arm/mach-sunxi/Makefile|  2 +-
>>>>  arch/arm/mach-sunxi/board.c |  4 ++--
>>>>  arch/arm/mach-sunxi/rmr_switch.S|  2 +-
>>>>  common/spl/Kconfig  |  4 ++--
>>>>  include/configs/sun50i.h|  2 +-
>>>>  10 files changed, 24 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
>>>> b/arch/arm/include/asm/arch-sunxi/boot0.h index
>>>> 46d0f0666c2b..e8e8e38f0556 100644
>>>> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
>>>> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
>>>> @@ -39,7 +39,7 @@
>>>>
>>>>.word   0xf57ff06f  // isb sy
>>>>.word   0xe320f003  // wfi
>>>>.word   0xeafd  // b   @wfi
>>>>
>>>> -#ifndef CONFIG_MACH_SUN50I_H6
>>>> +#ifndef CONFIG_SUN50I_GEN_H6
>>>>
>>>>.word   0x017000a0  // writeable RVBAR mapping address
>>>>  
>>>>  #else
>>>>  
>>>>.word   0x09010040  // writeable RVBAR mapping address
>>>>
>>>> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
>>>> b/arch/arm/include/asm/arch-sunxi/clock.h index
>>>> 5994130e6b54..cbbe5c7a1e68 100644
>>>> --- a/arch/arm/include/asm/arch-sunxi/clock.h
>>>> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
>>>> @@ -16,7 +16,7 @@
>>>>
>>>>  /* clock control module regs definition */
>>>>  #if defined(CONFIG_MACH_SUN8I_A83T)
>>>>  #include 
>>>>
>>>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>>>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>>>>
>>>>  #include 
>>>>  #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
>>>>  
>>>>defined(CONFIG_MACH_SUN50I)
>>>>
>>>> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
>>>> b/arch/arm/include/asm/arch-sunxi/cpu.h index 8b57d24e2f0c..b08f2023748c
>>>> 100644
>>>> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
>>>> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
>>>> @@ -8,7 +8,7 @@
>>>>
>>>>  #if defined(CONFIG_MACH_SUN9I)
>>>>  #include 
>>>>
>>>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>>>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>>>>
>>>>  #include 
>>>>  #else
>>>>  #include 
>>>>
>>>> diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
>>>> b/arch/arm/include/asm/arch-sunxi/timer.h index
>>>> 6f138d04b806..bb5626d893bb 100644
>>>> --- a/arch/arm/include/asm/arch-sunxi/timer.h
>>>> +++ b/arch/arm/include/asm/arch-sunxi/timer.h
>>>> @@ -76,7 +76,7 @@ struct sunxi_timer_reg {
>>>>
>>>>struct sunxi_tgp tgp[4];
>>>>u8 res5[8];
>>>>u32 cpu_cfg;
>>>>
>>>> -#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
>>>> +#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
>>>>
>>>>u8 res3[16];
>>>>struct sunxi_wdog wdog[5];  /* We have 5 watchdogs */
>>>>  
>>>>  #endif
>>>>
>>>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arc

Re: [PATCH 01/17] sunxi: Add support for AXP305 PMIC

[André Przywara]

On 03/01/2021 09:26, Jernej Skrabec wrote:
> This PMIC can be found on H616 boards and it's very similar to AXP805
> and AXP806.
>> Signed-off-by: Jernej Skrabec 

The existing sunxi PMIC code is the typical U-Boot mess, but I don't
want to block this series on a rework. I put some comments and ideas
below how to improve the whole "framework".

For this actual patch I checked the bits against the AXP305 datasheet,
it does what we need.

(reluctantly)
Reviewed-by: Andre Przywara 

Thanks,
Andre

> ---
>  arch/arm/mach-sunxi/pmic_bus.c |  6 +++
>  board/sunxi/board.c| 10 +++--
>  drivers/power/Kconfig  | 13 +-
>  drivers/power/Makefile |  1 +
>  drivers/power/axp305.c | 80 ++
>  include/axp305.h   | 17 
>  include/axp_pmic.h |  3 ++
>  7 files changed, 126 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/power/axp305.c
>  create mode 100644 include/axp305.h
> 
> diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
> index dea42de833f1..0394ce856448 100644
> --- a/arch/arm/mach-sunxi/pmic_bus.c
> +++ b/arch/arm/mach-sunxi/pmic_bus.c
> @@ -18,6 +18,8 @@
>  
>  #define AXP209_I2C_ADDR  0x34
>  
> +#define AXP305_I2C_ADDR  0x36
> +
>  #define AXP221_CHIP_ADDR 0x68
>  #define AXP221_CTRL_ADDR 0x3e
>  #define AXP221_INIT_DATA 0x3e
> @@ -64,6 +66,8 @@ int pmic_bus_read(u8 reg, u8 *data)
>   return i2c_read(AXP152_I2C_ADDR, reg, 1, data, 1);
>  #elif defined CONFIG_AXP209_POWER
>   return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
> +#elif defined CONFIG_AXP305_POWER
> + return i2c_read(AXP305_I2C_ADDR, reg, 1, data, 1);
>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
> CONFIG_AXP818_POWER
>  # ifdef CONFIG_MACH_SUN6I
>   return p2wi_read(reg, data);
> @@ -81,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data)
>   return i2c_write(AXP152_I2C_ADDR, reg, 1, , 1);
>  #elif defined CONFIG_AXP209_POWER
>   return i2c_write(AXP209_I2C_ADDR, reg, 1, , 1);
> +#elif defined CONFIG_AXP305_POWER
> + return i2c_write(AXP305_I2C_ADDR, reg, 1, , 1);
>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
> CONFIG_AXP818_POWER
>  # ifdef CONFIG_MACH_SUN6I
>   return p2wi_write(reg, data);
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 708a27ed78e9..54ff9bc92396 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -634,16 +634,18 @@ void sunxi_board_init(void)
>  #endif

This whole function is really a mess, but we can clean this up later.
I wonder if we can guard with the actual CONFIG_AXP_*_VOLT symbols
directly instead of specifying the list of PMICs requiring this rail
(this list is already in Kconfig).
Maybe with some macro magic to avoid the repetitions and move the ifdefs
out of the function?
power_failed |= axp_set_rail(dcdc1, DCDC1);
and assemble the function name and CONFIG_ symbol in that macro, plus
having the guard there?

>  
>  #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
> - defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> - defined CONFIG_AXP818_POWER
> + defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
> + defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
>   power_failed = axp_init();
>  
>  #if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
>   defined CONFIG_AXP818_POWER
>   power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
>  #endif
> +#if !defined(CONFIG_AXP305_POWER)
>   power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
>   power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
> +#endif
>  #if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
>   power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
>  #endif
> @@ -656,8 +658,10 @@ void sunxi_board_init(void)
>   defined CONFIG_AXP818_POWER
>   power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
>  #endif
> +#if !defined(CONFIG_AXP305_POWER)
>   power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
> -#if !defined(CONFIG_AXP152_POWER)
> +#endif
> +#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
>   power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
>  #endif
>  #ifdef CONFIG_AXP209_POWER

Verified this hunk by playing CPP and removing all non-applicable calls.
This ended up in:
power_failed = axp_init();
power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);

Which looks like the idea behind this patch, but is totally non-obvious
from the diff.

> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 02050f6f3569..d17cf2d9112a 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -48,6 +48,15 @@ config AXP221_POWER
>   Select this to enable support for the axp221/axp223 pmic found on most
>   

Re: [linux-sunxi] [PATCH v6 3/3] arm64: dts: sun50i: Add support for Orange Pi 3

[André Przywara]

On 10/01/2021 23:16, Samuel Holland wrote:
> On 1/10/21 1:29 PM, Jernej Skrabec wrote:
>> From: Andre Heider 
>>
>> dts file is taken from Linux 5.11-rc1 tag.
>>
>> The Bluetooth controller of this device ships with a default address,
>> use the new CONFIG_FIXUP_BDADDR option to fix it up.
> 
> This still references the old config name. It should be
> CONFIG_BLUETOOTH_DT_DEVICE_FIXUP.

Ah, thanks for pointing this out. I checked the usage in the code, but
missed the commit message.
Will fix it up in my branch.

Cheers,
Andre

Re: [PATCH v6 0/3] sunxi: Add support for OrangePi 3

[André Przywara]

On 10/01/2021 19:29, Jernej Skrabec wrote:
> This series introduces OrangePi 3 support.
> 
> Previous cover letter:
> This is just refreshed v4 from here:
> https://patchwork.ozlabs.org/project/uboot/list/?series=156657=*
> 
> Patches are only rebased, DT updated and defconfig regenerated, so
> I kept old tags. Only difference with old version is that this one
> does not sync H6 DT files. Becasue of that, this series should be
> applied on top of:
> https://patchwork.ozlabs.org/project/uboot/list/?series=222516

I applied and pushed 1/3 and 2/3.

Put 3/3 on my next branch, behind the H6 DT update, to be pushed as soon
as we get the RGMII PHY mode patch in.

Thanks!
Andre

> Please take a look.
> 
> Best regards,
> Jernej
> 
> Changes from v5:
> - Added tags
> - Renamed FIXUP_BDADDR -> BLUETOOTH_DT_DEVICE_FIXUP
> - Renamed fixup_bd_address() -> bluetooth_dt_fixup()
> - Removed CONFIG_PSCI_RESET from defconfig
> 
> Andre Heider (3):
>   sunxi: board: extract creating a unique sid into a helper function
>   arm: sunxi: add a config option to fixup a Bluetooth address
>   arm64: dts: sun50i: Add support for Orange Pi 3
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/sun50i-h6-orangepi-3.dts | 345 ++
>  arch/arm/mach-sunxi/Kconfig   |  11 +
>  board/sunxi/MAINTAINERS   |   5 +
>  board/sunxi/board.c   | 155 
>  configs/orangepi_3_defconfig  |  12 +
>  6 files changed, 474 insertions(+), 55 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h6-orangepi-3.dts
>  create mode 100644 configs/orangepi_3_defconfig
> 

Re: [PATCH] sunxi: dram: h6: Improve DDR3 config detection

[André Przywara]

On 10/01/2021 18:43, Jernej Škrabec wrote:
> Dne petek, 08. januar 2021 ob 03:01:42 CET je André Przywara napisal(a):
>> On 03/12/2020 17:46, Jernej Skrabec wrote:
>>> It turns out that in rare cases, current analytical approach to detect
>>> correct DRAM bus width and rank on H6 doesn't work. On some TV boxes
>>> with DDR3, incorrect DRAM configuration triggers write leveling error
>>> which immediately stops initialization process. Exact reason why this
>>> error appears isn't known. However, if correct configuration is used,
>>> initalization works without problem.
>>>
>>> In order to fix this issue, simply try another configuration when any
>>> kind of error appears during initialization, not just those related to
>>> rank and bus width.
>>
>> It's a bummer that this auto detection doesn't work, it looked to be the
>> right thing.
>> But I prefer functionality over pipe dreams ;-)
>>
>>>
>>> Tested-by: Thomas Graichen 
>>> Signed-off-by: Jernej Skrabec 

...

>>> +static void mctl_auto_detect_rank_width(struct dram_para *para)
>>> +{
>>> +   /* this is minimum size that it's supported */
>>> +   para->cols = 8;
>>> +   para->rows = 13;
>>> +
>>> +   /*
>>
>> Can you add here that former versions of this code tried to autodetect
>> rank and width, but this didn't work reliably? This would give people
>> some breadcrumbs to follow with git log/git annotate.
>>
>> Otherwise this is fine:
>>
>> Reviewed-by: Andre Przywara 
>> Tested-by: Andre Przywara  (on Pine H64)
>>
>> I can extend the commit while committing, if you like.
> 
> Please do. Thanks!

Done and applied!

Thanks,
Andre

Re: [PATCH v1] sunxi: board: Move USB ethernet initialization to board_late_init()

[André Przywara]

On 08/12/2020 15:45, Andy Shevchenko wrote:

Hi,

> For the sake of consistency (*) and order of initialization, i.e.
> after we have got the ethernet address, interrupt and timer initialized,
> try to initialize USB ethernet gadget.
> 
> *) for example, zynqmp uses same order.
> 
> Signed-off-by: Andy Shevchenko 

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

I tried on: Pine64-LTS, Pine H64, OrangePi Zero, Banana Pi M1. Could do
TFTP correctly. Also compared the MAC addresses before and after.

I will queue this for the merge window, to get some more exposure.

Cheers,
Andre

> ---
>  arch/arm/Kconfig| 1 +
>  board/sunxi/board.c | 5 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5903c093705a..3d9be8a7507e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1045,6 +1045,7 @@ config ARCH_SUNXI
>   select SPL_USE_TINY_PRINTF
>   select USE_PREBOOT
>   select SYS_RELOC_GD_ENV_ADDR
> + imply BOARD_LATE_INIT
>   imply CMD_DM
>   imply CMD_GPT
>   imply CMD_UBI if MTD_RAW_NAND
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 708a27ed78e9..77e464718846 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -890,6 +890,11 @@ int misc_init_r(void)
>  
>   setup_environment(gd->fdt_blob);
>  
> + return 0;
> +}
> +
> +int board_late_init(void)
> +{
>  #ifdef CONFIG_USB_ETHER
>   usb_ether_init();
>  #endif
> 

Re: [PATCH] sunxi: dram: h6: Improve DDR3 config detection

[André Przywara]

On 03/12/2020 17:46, Jernej Skrabec wrote:
> It turns out that in rare cases, current analytical approach to detect
> correct DRAM bus width and rank on H6 doesn't work. On some TV boxes
> with DDR3, incorrect DRAM configuration triggers write leveling error
> which immediately stops initialization process. Exact reason why this
> error appears isn't known. However, if correct configuration is used,
> initalization works without problem.
> 
> In order to fix this issue, simply try another configuration when any
> kind of error appears during initialization, not just those related to
> rank and bus width.

It's a bummer that this auto detection doesn't work, it looked to be the
right thing.
But I prefer functionality over pipe dreams ;-)

> 
> Tested-by: Thomas Graichen 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/mach-sunxi/dram_sun50i_h6.c | 95 +++-
>  1 file changed, 51 insertions(+), 44 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> index 9e34da474798..1cde6132be2c 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -37,9 +37,9 @@
>  
>  static void mctl_sys_init(struct dram_para *para);
>  static void mctl_com_init(struct dram_para *para);
> -static void mctl_channel_init(struct dram_para *para);
> +static bool mctl_channel_init(struct dram_para *para);
>  
> -static void mctl_core_init(struct dram_para *para)
> +static bool mctl_core_init(struct dram_para *para)
>  {
>   mctl_sys_init(para);
>   mctl_com_init(para);
> @@ -51,7 +51,7 @@ static void mctl_core_init(struct dram_para *para)
>   default:
>   panic("Unsupported DRAM type!");
>   };
> - mctl_channel_init(para);
> + return mctl_channel_init(para);
>  }
>  
>  /* PHY initialisation */
> @@ -411,7 +411,7 @@ static void mctl_bit_delay_set(struct dram_para *para)
>   }
>  }
>  
> -static void mctl_channel_init(struct dram_para *para)
> +static bool mctl_channel_init(struct dram_para *para)
>  {
>   struct sunxi_mctl_com_reg * const mctl_com =
>   (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> @@ -528,46 +528,15 @@ static void mctl_channel_init(struct dram_para *para)
>   clrbits_le32(_phy->dx[i].gcr[3], ~0x3);
>   udelay(10);
>  
> - if (readl(_phy->pgsr[0]) & 0x40)
> - {
> - /* Check for single rank and optionally half DQ. */
> - if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 2 &&
> - (readl(_phy->dx[1].rsr[0]) & 0x3) == 2) {
> - para->ranks = 1;
> -
> - if ((readl(_phy->dx[2].rsr[0]) & 0x3) != 2 ||
> - (readl(_phy->dx[3].rsr[0]) & 0x3) != 2)
> - para->bus_full_width = 0;
> -
> - /* Restart DRAM initialization from scratch. */
> - mctl_core_init(para);
> - return;
> - }
> -
> - /*
> -  * Check for dual rank and half DQ. NOTE: This combination
> -  * is highly unlikely and was not tested. Condition is the
> -  * same as in libdram, though.
> -  */
> - if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 0 &&
> - (readl(_phy->dx[1].rsr[0]) & 0x3) == 0) {
> - para->bus_full_width = 0;
> -
> - /* Restart DRAM initialization from scratch. */
> - mctl_core_init(para);
> - return;
> - }
> -
> - panic("This DRAM setup is currently not supported.\n");
> - }
> -
>   if (readl(_phy->pgsr[0]) & 0xff0) {
>   /* Oops! There's something wrong! */
>   debug("PLL = %x\n", readl(0x3001010));
>   debug("DRAM PHY PGSR0 = %x\n", readl(_phy->pgsr[0]));
>   for (i = 0; i < 4; i++)
>   debug("DRAM PHY DX%dRSR0 = %x\n", i, 
> readl(_phy->dx[i].rsr[0]));
> - panic("Error while initializing DRAM PHY!\n");
> + debug("Error while initializing DRAM PHY!\n");
> +
> + return false;
>   }
>  
>   if (sunxi_dram_is_lpddr(para->type))
> @@ -582,13 +551,54 @@ static void mctl_channel_init(struct dram_para *para)
>   writel(0x, _com->maer0);
>   writel(0x7ff, _com->maer1);
>   writel(0x, _com->maer2);
> +
> + return true;
> +}
> +
> +static void mctl_auto_detect_rank_width(struct dram_para *para)
> +{
> + /* this is minimum size that it's supported */
> + para->cols = 8;
> + para->rows = 13;
> +
> + /*

Can you add here that former versions of this code tried to autodetect
rank and width, but this didn't work reliably? This would give people
some breadcrumbs to follow with git log/git annotate.

Otherwise this is fine:

Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara  (on Pine H64)

I can extend 

Re: [PATCH v5 3/3] arm64: dts: sun50i: Add support for Orange Pi 3

[André Przywara]

On 03/01/2021 18:36, Jernej Skrabec wrote:
> From: Andre Heider 

Hi,

> dts file is taken from Linux 5.11-rc1 tag.
> 
> The Bluetooth controller of this device ships with a default address,
> use the new CONFIG_FIXUP_BDADDR option to fix it up.
> 
> Signed-off-by: Andre Heider 
> Acked-by: Maxime Ripard 
> [Updated OrangePi 3 DT, rebase and config update]
> Signed-off-by: Jernej Skrabec 

As already mentioned, this CONFIG_PSCI_RESET removal should go.
The rest looks alright, the .dts is identical to the Linux version.

With that removed:

Reviewed-by: Andre Przywara 

Thanks,
Andre


> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/sun50i-h6-orangepi-3.dts | 345 ++
>  board/sunxi/MAINTAINERS   |   5 +
>  configs/orangepi_3_defconfig  |  13 +
>  4 files changed, 364 insertions(+)
>  create mode 100644 arch/arm/dts/sun50i-h6-orangepi-3.dts
>  create mode 100644 configs/orangepi_3_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e00aed1ec207..607571d04b25 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -605,6 +605,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
>   sun50i-h5-orangepi-zero-plus2.dtb
>  dtb-$(CONFIG_MACH_SUN50I_H6) += \
>   sun50i-h6-beelink-gs1.dtb \
> + sun50i-h6-orangepi-3.dtb \
>   sun50i-h6-orangepi-lite2.dtb \
>   sun50i-h6-orangepi-one-plus.dtb \
>   sun50i-h6-pine-h64.dtb \
> diff --git a/arch/arm/dts/sun50i-h6-orangepi-3.dts 
> b/arch/arm/dts/sun50i-h6-orangepi-3.dts
> new file mode 100644
> index ..15c9dd8c4479
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-orangepi-3.dts
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2019 Ondřej Jirman 
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "OrangePi 3";
> + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> + ext_osc32k: ext_osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "ext_osc32k";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +
> + reg_vcc33_wifi: vcc33-wifi {
> + /* Always on 3.3V regulator for WiFi and BT */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc33-wifi";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + vin-supply = <_vcc5v>;
> + };
> +
> + reg_vcc_wifi_io: vcc-wifi-io {
> + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-wifi-io";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + vin-supply = <_vcc33_wifi>;
> + };
> +
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = < 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> +};
> +
> + {
> + cpu-supply = <_dcdca>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + mali-supply = <_dcdcc>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + 

Re: [PATCH v5 2/3] arm: sunxi: add a config option to fixup a Bluetooth address

[André Przywara]

On 03/01/2021 18:36, Jernej Skrabec wrote:

Hi,

> From: Andre Heider 
> 
> Some Bluetooth controllers, like the BCM4345C5 of the Orange Pi 3,
> ship with the controller default address.
> 
> Add a config option to fix it up so it can function properly.
> 
> Signed-off-by: Andre Heider 
> Tested-by: Ondrej Jirman 
> Acked-by: Maxime Ripard 
> [rebased]
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/mach-sunxi/Kconfig | 11 +++
>  board/sunxi/board.c | 34 ++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 49ef217f08c0..269aef5f01a1 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1016,4 +1016,15 @@ config PINEPHONE_DT_SELECTION
> Enable this option to automatically select the device tree for the
> correct PinePhone hardware revision during boot.
>  
> +config FIXUP_BDADDR

This naming is a bit generic, and the BD in there is slightly confusing.
I understand that this is the official term used in Bluetooth land, but
it would be helpful to put this piece of context into the symbol name as
well. Especially since "bd" is used for "board" all over the place in
U-Boot.
Maybe stay closer to the actual content of the symbol, which is the DT
compatible *name*, and *not* an address? BLUETOOTH_DT_DEVICE_FIXUP or
the like?

> + string "Fixup the Bluetooth controller address"
> + default ""
> + help
> +   This option specifies the DT compatible name of the Bluetooth
> +   controller for which to set the "local-bd-address" property.
> +   Set this option if your device ships with the Bluetooth controller
> +   default address.
> +   The used address is "bdaddr" if set, and "ethaddr" with the LSB
> +   flipped elsewise.
> +
>  endif
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 4a29e351141b..d19119b7eb36 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -908,6 +908,38 @@ int misc_init_r(void)
>   return 0;
>  }
>  
> +static void fixup_bd_address(void *blob)

similar comment to the naming in this function, to avoid the "bd" in here.

The code itself looks fine, it's really just about the naming.
The variable names inside the function are fine, since the context is clear.

Thanks!
Andre


> +{
> + /* Some devices ship with a Bluetooth controller default address.
> +  * Set a valid address through the device tree.
> +  */
> + uchar tmp[ETH_ALEN], bdaddr[ETH_ALEN];
> + unsigned int sid[4];
> + int i;
> +
> + if (!CONFIG_FIXUP_BDADDR[0])
> + return;
> +
> + if (eth_env_get_enetaddr("bdaddr", tmp)) {
> + /* Convert between the binary formats of the corresponding 
> stacks */
> + for (i = 0; i < ETH_ALEN; ++i)
> + bdaddr[i] = tmp[ETH_ALEN - i - 1];
> + } else {
> + if (!get_unique_sid(sid))
> + return;
> +
> + bdaddr[0] = ((sid[3] >>  0) & 0xff) ^ 1;
> + bdaddr[1] = (sid[3] >>  8) & 0xff;
> + bdaddr[2] = (sid[3] >> 16) & 0xff;
> + bdaddr[3] = (sid[3] >> 24) & 0xff;
> + bdaddr[4] = (sid[0] >>  0) & 0xff;
> + bdaddr[5] = 0x02;
> + }
> +
> + do_fixup_by_compat(blob, CONFIG_FIXUP_BDADDR,
> +"local-bd-address", bdaddr, ETH_ALEN, 1);
> +}
> +
>  int ft_board_setup(void *blob, struct bd_info *bd)
>  {
>   int __maybe_unused r;
> @@ -918,6 +950,8 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>*/
>   setup_environment(blob);
>  
> + fixup_bd_address(blob);
> +
>  #ifdef CONFIG_VIDEO_DT_SIMPLEFB
>   r = sunxi_simplefb_setup(blob);
>   if (r)
> 

Re: [PATCH v5 1/3] sunxi: board: extract creating a unique sid into a helper function

[André Przywara]

On 03/01/2021 18:36, Jernej Skrabec wrote:
> From: Andre Heider 
> 
> Refactor setup_environment() so we can use the created sid for a
> Bluetooth address too.
> 
> Signed-off-by: Andre Heider 
> Acked-by: Maxime Ripard 
> [rebased]
> Signed-off-by: Jernej Skrabec 

Confirmed to be indeed just moving this code out and reversing the check.

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/sunxi/board.c | 121 
>  1 file changed, 66 insertions(+), 55 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 708a27ed78e9..4a29e351141b 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -789,6 +789,38 @@ static void parse_spl_header(const uint32_t spl_addr)
>   env_set_hex("fel_scriptaddr", spl->fel_script_address);
>  }
>  
> +static bool get_unique_sid(unsigned int *sid)
> +{
> + if (sunxi_get_sid(sid) != 0)
> + return false;
> +
> + if (!sid[0])
> + return false;
> +
> + /*
> +  * The single words 1 - 3 of the SID have quite a few bits
> +  * which are the same on many models, so we take a crc32
> +  * of all 3 words, to get a more unique value.
> +  *
> +  * Note we only do this on newer SoCs as we cannot change
> +  * the algorithm on older SoCs since those have been using
> +  * fixed mac-addresses based on only using word 3 for a
> +  * long time and changing a fixed mac-address with an
> +  * u-boot update is not good.
> +  */
> +#if !defined(CONFIG_MACH_SUN4I) && !defined(CONFIG_MACH_SUN5I) && \
> +!defined(CONFIG_MACH_SUN6I) && !defined(CONFIG_MACH_SUN7I) && \
> +!defined(CONFIG_MACH_SUN8I_A23) && !defined(CONFIG_MACH_SUN8I_A33)
> + sid[3] = crc32(0, (unsigned char *)[1], 12);
> +#endif
> +
> + /* Ensure the NIC specific bytes of the mac are not all 0 */
> + if ((sid[3] & 0xff) == 0)
> + sid[3] |= 0x80;
> +
> + return true;
> +}
> +
>  /*
>   * Note this function gets called multiple times.
>   * It must not make any changes to env variables which already exist.
> @@ -799,61 +831,40 @@ static void setup_environment(const void *fdt)
>   unsigned int sid[4];
>   uint8_t mac_addr[6];
>   char ethaddr[16];
> - int i, ret;
> -
> - ret = sunxi_get_sid(sid);
> - if (ret == 0 && sid[0] != 0) {
> - /*
> -  * The single words 1 - 3 of the SID have quite a few bits
> -  * which are the same on many models, so we take a crc32
> -  * of all 3 words, to get a more unique value.
> -  *
> -  * Note we only do this on newer SoCs as we cannot change
> -  * the algorithm on older SoCs since those have been using
> -  * fixed mac-addresses based on only using word 3 for a
> -  * long time and changing a fixed mac-address with an
> -  * u-boot update is not good.
> -  */
> -#if !defined(CONFIG_MACH_SUN4I) && !defined(CONFIG_MACH_SUN5I) && \
> -!defined(CONFIG_MACH_SUN6I) && !defined(CONFIG_MACH_SUN7I) && \
> -!defined(CONFIG_MACH_SUN8I_A23) && !defined(CONFIG_MACH_SUN8I_A33)
> - sid[3] = crc32(0, (unsigned char *)[1], 12);
> -#endif
> -
> - /* Ensure the NIC specific bytes of the mac are not all 0 */
> - if ((sid[3] & 0xff) == 0)
> - sid[3] |= 0x80;
> -
> - for (i = 0; i < 4; i++) {
> - sprintf(ethaddr, "ethernet%d", i);
> - if (!fdt_get_alias(fdt, ethaddr))
> - continue;
> -
> - if (i == 0)
> - strcpy(ethaddr, "ethaddr");
> - else
> - sprintf(ethaddr, "eth%daddr", i);
> -
> - if (env_get(ethaddr))
> - continue;
> -
> - /* Non OUI / registered MAC address */
> - mac_addr[0] = (i << 4) | 0x02;
> - mac_addr[1] = (sid[0] >>  0) & 0xff;
> - mac_addr[2] = (sid[3] >> 24) & 0xff;
> - mac_addr[3] = (sid[3] >> 16) & 0xff;
> - mac_addr[4] = (sid[3] >>  8) & 0xff;
> - mac_addr[5] = (sid[3] >>  0) & 0xff;
> -
> - eth_env_set_enetaddr(ethaddr, mac_addr);
> - }
> -
> - if (!env_get("serial#")) {
> - snprintf(serial_string, sizeof(serial_string),
> - "%08x%08x", sid[0], sid[3]);
> -
> - env_set("serial#", serial_string);
> - }
> + int i;
> +
> + if (!get_unique_sid(sid))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + sprintf(ethaddr, "ethernet%d", i);
> + if (!fdt_get_alias(fdt, ethaddr))
> + continue;
> +
> + if (i == 0)
> +  

Re: [PATCH v3 2/2] sunxi: Add support for Tanix TX6

[André Przywara]

On 06/01/2021 17:02, Jernej Skrabec wrote:
> This commit adds support for Tanix TX6 TV box, based on H6. It's low end
> H6 board, with 3 GiB of RAM, eMMC, fast ethernet, USB, IR and other
> peripherals.
> 
> DT file is taken from Linux 5.11-rc1 release.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Andre Przywara 

Thanks!
Andre

> ---
>  arch/arm/dts/Makefile|   3 +-
>  arch/arm/dts/sun50i-h6-tanix-tx6.dts | 124 +++
>  board/sunxi/MAINTAINERS  |   6 ++
>  configs/tanix_tx6_defconfig  |  10 +++
>  4 files changed, 142 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6.dts
>  create mode 100644 configs/tanix_tx6_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f826..e00aed1ec207 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -607,7 +607,8 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
>   sun50i-h6-beelink-gs1.dtb \
>   sun50i-h6-orangepi-lite2.dtb \
>   sun50i-h6-orangepi-one-plus.dtb \
> - sun50i-h6-pine-h64.dtb
> + sun50i-h6-pine-h64.dtb \
> + sun50i-h6-tanix-tx6.dtb
>  dtb-$(CONFIG_MACH_SUN50I) += \
>   sun50i-a64-amarula-relic.dtb \
>   sun50i-a64-bananapi-m64.dtb \
> diff --git a/arch/arm/dts/sun50i-h6-tanix-tx6.dts 
> b/arch/arm/dts/sun50i-h6-tanix-tx6.dts
> new file mode 100644
> index ..be81330db14f
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-tanix-tx6.dts
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (c) 2019 Jernej Skrabec 
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Tanix TX6";
> + compatible = "oranth,tanix-tx6", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_vdd_cpu_gpu: vdd-cpu-gpu {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-cpu-gpu";
> + regulator-min-microvolt = <1135000>;
> + regulator-max-microvolt = <1135000>;
> + };
> +};
> +
> + {
> + cpu-supply = <_vdd_cpu_gpu>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + mali-supply = <_vdd_cpu_gpu>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_vcc3v3>;
> + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_ir {
> + linux,rc-map-name = "rc-tanix-tx5max";
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ph_pins>;
> + status = "okay";
> +};
> +
> + {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index d3755ae41a9d..1b37a9899edd 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -489,6 +489,12 @@ S:   Maintained
>  F:   configs/Sunchip_CX-A99_defconfig
>  W:   https://linux-sunxi.org/Sunchip_CX-A99
>  
> +TANIX TX6 BOARD
> +M:   Jernej Skrabec 
> +S:   Maintained
> +F:   configs/tanix_tx6_defconfig
> +W:   https://linux-sunxi.org/Tanix_TX6
> +
>  TBS A711 BOARD
>  M:   Maxime Ripard 
>  S:   Maintained
> diff --git a/configs/tanix_tx6_defconfig b/configs/tanix_tx6_defconfig
> new file mode 100644
> index ..9ce812ecc35d
> --- /dev/null
> +++ b/configs/tanix_tx6_defconfig
> @@ -0,0 +1,10 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN50I_H6=y
> +CONFIG_SUNXI_DRAM_H6_DDR3_1333=y
> +CONFIG_DRAM_CLK=648
> +CONFIG_MMC0_CD_PIN="PF6"
> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-tanix-tx6"
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> 

Re: [PATCH v3 1/2] ARM: dts: sunxi: h6: Update DT files

[André Przywara]

On 06/01/2021 17:02, Jernej Skrabec wrote:
> Updated H6 DT files are based on Linux 5.11-rc1 release.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Andre Przywara 

Two things to note:
- This relies on the U-Boot patch to sun8i-emac to recognise rgmii-id
and friends, otherwise Ethernet won't work. The patch should ideally be
merged before those ones.

- This decreases DT compatibilty with older kernels, which don't know
about the H6 RTC (introduced in Linux v5.4). The IOSC fixed clock got
replaced by < 2>, so this won't be available everywhere.

Cheers,
Andre

> ---
>  arch/arm/dts/sun50i-h6-beelink-gs1.dts   |  70 +++-
>  arch/arm/dts/sun50i-h6-cpu-opp.dtsi  | 117 ++
>  arch/arm/dts/sun50i-h6-orangepi-lite2.dts|  71 +++-
>  arch/arm/dts/sun50i-h6-orangepi-one-plus.dts |  41 +-
>  arch/arm/dts/sun50i-h6-orangepi.dtsi |  72 +++-
>  arch/arm/dts/sun50i-h6-pine-h64.dts  | 102 +++--
>  arch/arm/dts/sun50i-h6.dtsi  | 394 +--
>  7 files changed, 794 insertions(+), 73 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> 
> diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts 
> b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> index 0dc33c90dd60..7c9dbde645b5 100644
> --- a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> @@ -1,11 +1,10 @@
> -// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> -/*
> - * Copyright (C) 2019 Clément Péron 
> - */
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2019 Clément Péron 
>  
>  /dts-v1/;
>  
>  #include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
>  
>  #include 
>  
> @@ -25,6 +24,7 @@
>   connector {
>   compatible = "hdmi-connector";
>   type = "a";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
>  
>   port {
>   hdmi_con_in: endpoint {
> @@ -33,6 +33,13 @@
>   };
>   };
>  
> + ext_osc32k: ext_osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "ext_osc32k";
> + };
> +
>   leds {
>   compatible = "gpio-leds";
>  
> @@ -51,12 +58,38 @@
>   regulator-max-microvolt = <500>;
>   regulator-always-on;
>   };
> +
> + sound-spdif {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "sun50i-h6-spdif";
> +
> + simple-audio-card,cpu {
> + sound-dai = <>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <_out>;
> + };
> + };
> +
> + spdif_out: spdif-out {
> + #sound-dai-cells = <0>;
> + compatible = "linux,spdif-dit";
> + };
> +};
> +
> + {
> + cpu-supply = <_dcdca>;
>  };
>  
>   {
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -64,12 +97,17 @@
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_rgmii_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>   phy-handle = <_rgmii_phy>;
>   phy-supply = <_aldo2>;
>   status = "okay";
>  };
>  
> + {
> + mali-supply = <_dcdcc>;
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -201,13 +239,16 @@
>   reg_dcdca: dcdca {
>   regulator-always-on;
>   regulator-min-microvolt = <81>;
> - regulator-max-microvolt = <108>;
> + regulator-max-microvolt = <116>;
> + regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-cpu";
>   };
>  
>   reg_dcdcc: dcdcc {
> + regulator-enable-ramp-delay = <32000>;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <108>;
> + regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-gpu";
>   };
>  
> @@ -232,6 +273,11 @@
>   };
>  };
>  
> +_ir {
> + linux,rc-map-name = "rc-beelink-gs1";
> + status = "okay";
> +};
> +
>  _pio {
>   /*
>* PL0 and PL1 are used for PMIC I2C
> @@ -243,6 +289,14 @@
>   vcc-pm-supply = <_aldo1>;
>  };
>  
> + {
> + clocks = <_osc32k>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_ph_pins>;
> @@ -258,3 +312,7 @@
>   usb0_vbus-supply = <_vcc5v>;
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/sun50i-h6-cpu-opp.dtsi 
> b/arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> new file mode 100644
> index 

Re: [PATCH v4 3/3] sunxi: Use mkimage for SPL boot image generation

[André Przywara]

On 07/01/2021 12:36, Simon Glass wrote:

Hi Simon,

thanks for the review!

> On Wed, 6 Jan 2021 at 02:25, Andre Przywara  wrote:
>>
>> Switch the SPL boot image generation from using mksunxiboot to the new
>> sunxi_egon format of mkimage.
>>
>> Verified to create identical results for all 152 Allwinner boards.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  scripts/Makefile.spl | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Do we need to delete the old tool?

I would rather not quite do this yet, instead leave it around for a bit.
There is for instance sunxi-tools, that relies on this, and it's also
packaged as part of Debian's u-boot-tools package.
We surely will transition them over, but this might take a while.

Cheers,
Andre

Re: [PATCH 01/17] sunxi: Add support for AXP305 PMIC

[André Przywara]

On 06/01/2021 23:33, Jaehoon Chung wrote:
> On 1/6/21 7:11 PM, André Przywara wrote:
>> On 05/01/2021 22:36, Jaehoon Chung wrote:
>>
>> Hi,
>>
>> thanks for having a look!
>>
>>> Hi Jernej
>>>
>>> On 1/3/21 6:26 PM, Jernej Skrabec wrote:
>>>> This PMIC can be found on H616 boards and it's very similar to AXP805
>>>> and AXP806.
>>>
>>> Is there any plan to cleanup codes?
>>
>> There is no support for either of these, we use the PMICs only in
>> Trusted Firmware or Linux. So nothing to consolidate, yet. This might
>> change in the future, and then of course we will use a common code base.
>>
>>>
>>>>
>>>> Signed-off-by: Jernej Skrabec 
>>>> ---
>>>>  arch/arm/mach-sunxi/pmic_bus.c |  6 +++
>>>>  board/sunxi/board.c| 10 +++--
>>>>  drivers/power/Kconfig  | 13 +-
>>>>  drivers/power/Makefile |  1 +
>>>>  drivers/power/axp305.c | 80 ++
>>>>  include/axp305.h   | 17 
>>>>  include/axp_pmic.h |  3 ++
>>>>  7 files changed, 126 insertions(+), 4 deletions(-)
>>>>  create mode 100644 drivers/power/axp305.c
>>>>  create mode 100644 include/axp305.h
>>>>
>>>> diff --git a/arch/arm/mach-sunxi/pmic_bus.c 
>>>> b/arch/arm/mach-sunxi/pmic_bus.c
>>>> index dea42de833f1..0394ce856448 100644
>>>> --- a/arch/arm/mach-sunxi/pmic_bus.c
>>>> +++ b/arch/arm/mach-sunxi/pmic_bus.c
>>>> @@ -18,6 +18,8 @@
>>>>  
>>>>  #define AXP209_I2C_ADDR   0x34
>>>>  
>>>> +#define AXP305_I2C_ADDR   0x36
>>>> +
>>>>  #define AXP221_CHIP_ADDR  0x68
>>>>  #define AXP221_CTRL_ADDR  0x3e
>>>>  #define AXP221_INIT_DATA  0x3e
>>>> @@ -64,6 +66,8 @@ int pmic_bus_read(u8 reg, u8 *data)
>>>>return i2c_read(AXP152_I2C_ADDR, reg, 1, data, 1);
>>>>  #elif defined CONFIG_AXP209_POWER
>>>>return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
>>>> +#elif defined CONFIG_AXP305_POWER
>>>> +  return i2c_read(AXP305_I2C_ADDR, reg, 1, data, 1);
>>>>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || 
>>>> defined CONFIG_AXP818_POWER
>>>>  # ifdef CONFIG_MACH_SUN6I
>>>>return p2wi_read(reg, data);
>>>> @@ -81,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data)
>>>>return i2c_write(AXP152_I2C_ADDR, reg, 1, , 1);
>>>>  #elif defined CONFIG_AXP209_POWER
>>>>return i2c_write(AXP209_I2C_ADDR, reg, 1, , 1);
>>>> +#elif defined CONFIG_AXP305_POWER
>>>> +  return i2c_write(AXP305_I2C_ADDR, reg, 1, , 1);
>>>>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || 
>>>> defined CONFIG_AXP818_POWER
>>>>  # ifdef CONFIG_MACH_SUN6I
>>>>return p2wi_write(reg, data);
>>>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>>>> index 708a27ed78e9..54ff9bc92396 100644
>>>> --- a/board/sunxi/board.c
>>>> +++ b/board/sunxi/board.c
>>>> @@ -634,16 +634,18 @@ void sunxi_board_init(void)
>>>>  #endif
>>>>  
>>>>  #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
>>>> -  defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
>>>> -  defined CONFIG_AXP818_POWER
>>>> +  defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
>>>> +  defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
>>>>power_failed = axp_init();
>>>>  
>>>>  #if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
>>>>defined CONFIG_AXP818_POWER
>>>>power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
>>>>  #endif
>>>> +#if !defined(CONFIG_AXP305_POWER)
>>>>power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
>>>>power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
>>>> +#endif
>>>>  #if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
>>>>power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
>>>>  #endif
>>>> @@ -656,8 +658,10 @@ void sunxi_board_init(void)
>>>>defined CONFIG_AXP818_POWER
>>>>power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
>>>

Re: [PATCH v2 2/2] sunxi: Add support for Tanix TX6

[André Przywara]

On 03/01/2021 10:00, Jernej Skrabec wrote:
> This commit adds support for Tanix TX6 TV box, based on H6. It's low end
> H6 board, with 3 GiB of RAM, eMMC, fast ethernet, USB, IR and other
> peripherals.
> 
> DT file is taken from Linux 5.11-rc1 release.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/dts/Makefile|   3 +-
>  arch/arm/dts/sun50i-h6-tanix-tx6.dts | 124 +++
>  board/sunxi/MAINTAINERS  |   6 ++
>  configs/tanix_tx6_defconfig  |  11 +++
>  4 files changed, 143 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6.dts
>  create mode 100644 configs/tanix_tx6_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f826..e00aed1ec207 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -607,7 +607,8 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
>   sun50i-h6-beelink-gs1.dtb \
>   sun50i-h6-orangepi-lite2.dtb \
>   sun50i-h6-orangepi-one-plus.dtb \
> - sun50i-h6-pine-h64.dtb
> + sun50i-h6-pine-h64.dtb \
> + sun50i-h6-tanix-tx6.dtb
>  dtb-$(CONFIG_MACH_SUN50I) += \
>   sun50i-a64-amarula-relic.dtb \
>   sun50i-a64-bananapi-m64.dtb \
> diff --git a/arch/arm/dts/sun50i-h6-tanix-tx6.dts 
> b/arch/arm/dts/sun50i-h6-tanix-tx6.dts
> new file mode 100644
> index ..be81330db14f
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-tanix-tx6.dts
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (c) 2019 Jernej Skrabec 
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Tanix TX6";
> + compatible = "oranth,tanix-tx6", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_vdd_cpu_gpu: vdd-cpu-gpu {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-cpu-gpu";
> + regulator-min-microvolt = <1135000>;
> + regulator-max-microvolt = <1135000>;
> + };
> +};
> +
> + {
> + cpu-supply = <_vdd_cpu_gpu>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + mali-supply = <_vdd_cpu_gpu>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_vcc3v3>;
> + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_ir {
> + linux,rc-map-name = "rc-tanix-tx5max";
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ph_pins>;
> + status = "okay";
> +};
> +
> + {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index d3755ae41a9d..1b37a9899edd 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -489,6 +489,12 @@ S:   Maintained
>  F:   configs/Sunchip_CX-A99_defconfig
>  W:   https://linux-sunxi.org/Sunchip_CX-A99
>  
> +TANIX TX6 BOARD
> +M:   Jernej Skrabec 
> +S:   Maintained
> +F:   configs/tanix_tx6_defconfig
> +W:   https://linux-sunxi.org/Tanix_TX6
> +
>  TBS A711 BOARD
>  M:   Maxime Ripard 
>  S:   Maintained
> diff --git a/configs/tanix_tx6_defconfig b/configs/tanix_tx6_defconfig
> new file mode 100644
> index ..5b93d1c956fe
> --- /dev/null
> +++ b/configs/tanix_tx6_defconfig
> @@ -0,0 +1,11 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN50I_H6=y
> +CONFIG_SUNXI_DRAM_H6_DDR3_1333=y
> +CONFIG_DRAM_CLK=648
> +CONFIG_MMC0_CD_PIN="PF6"
> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> +# CONFIG_PSCI_RESET is not set

This line is not needed. I know it's in every other H6 defconfig, but it
should go there as well (will try to send patches).

The rest looks alright.

Cheers,
Andre

> 

Re: [PATCH v2 1/2] ARM: dts: sunxi: h6: Update DT files

[André Przywara]

On 03/01/2021 10:00, Jernej Skrabec wrote:
> Updated H6 DT files are based on Linux 5.11-rc1 release.
> 
> Signed-off-by: Jernej Skrabec 

That looks alright, but it seems like the OrangePi One Plus .dts is not
updated?

Cheers,
Andre

> ---
>  arch/arm/dts/sun50i-h6-beelink-gs1.dts|  70 +++-
>  arch/arm/dts/sun50i-h6-cpu-opp.dtsi   | 117 +++
>  arch/arm/dts/sun50i-h6-orangepi-lite2.dts |  71 +++-
>  arch/arm/dts/sun50i-h6-orangepi.dtsi  |  72 +++-
>  arch/arm/dts/sun50i-h6-pine-h64.dts   | 102 --
>  arch/arm/dts/sun50i-h6.dtsi   | 394 --
>  6 files changed, 758 insertions(+), 68 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> 
> diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts 
> b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> index 0dc33c90dd60..7c9dbde645b5 100644
> --- a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> @@ -1,11 +1,10 @@
> -// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> -/*
> - * Copyright (C) 2019 Clément Péron 
> - */
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2019 Clément Péron 
>  
>  /dts-v1/;
>  
>  #include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
>  
>  #include 
>  
> @@ -25,6 +24,7 @@
>   connector {
>   compatible = "hdmi-connector";
>   type = "a";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
>  
>   port {
>   hdmi_con_in: endpoint {
> @@ -33,6 +33,13 @@
>   };
>   };
>  
> + ext_osc32k: ext_osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "ext_osc32k";
> + };
> +
>   leds {
>   compatible = "gpio-leds";
>  
> @@ -51,12 +58,38 @@
>   regulator-max-microvolt = <500>;
>   regulator-always-on;
>   };
> +
> + sound-spdif {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "sun50i-h6-spdif";
> +
> + simple-audio-card,cpu {
> + sound-dai = <>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <_out>;
> + };
> + };
> +
> + spdif_out: spdif-out {
> + #sound-dai-cells = <0>;
> + compatible = "linux,spdif-dit";
> + };
> +};
> +
> + {
> + cpu-supply = <_dcdca>;
>  };
>  
>   {
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -64,12 +97,17 @@
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_rgmii_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>   phy-handle = <_rgmii_phy>;
>   phy-supply = <_aldo2>;
>   status = "okay";
>  };
>  
> + {
> + mali-supply = <_dcdcc>;
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -201,13 +239,16 @@
>   reg_dcdca: dcdca {
>   regulator-always-on;
>   regulator-min-microvolt = <81>;
> - regulator-max-microvolt = <108>;
> + regulator-max-microvolt = <116>;
> + regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-cpu";
>   };
>  
>   reg_dcdcc: dcdcc {
> + regulator-enable-ramp-delay = <32000>;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <108>;
> + regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-gpu";
>   };
>  
> @@ -232,6 +273,11 @@
>   };
>  };
>  
> +_ir {
> + linux,rc-map-name = "rc-beelink-gs1";
> + status = "okay";
> +};
> +
>  _pio {
>   /*
>* PL0 and PL1 are used for PMIC I2C
> @@ -243,6 +289,14 @@
>   vcc-pm-supply = <_aldo1>;
>  };
>  
> + {
> + clocks = <_osc32k>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_ph_pins>;
> @@ -258,3 +312,7 @@
>   usb0_vbus-supply = <_vcc5v>;
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/sun50i-h6-cpu-opp.dtsi 
> b/arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> new file mode 100644
> index ..1a5eddc5a40f
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Ondrej Jirman 
> +// Copyright (C) 2020 Clément Péron 
> +
> +/ {
> + cpu_opp_table: cpu-opp-table {
> + compatible = "allwinner,sun50i-h6-operating-points";
> + nvmem-cells = <_speed_grade>;
> +   

Re: [PATCH 01/17] sunxi: Add support for AXP305 PMIC

[André Przywara]

On 05/01/2021 22:36, Jaehoon Chung wrote:

Hi,

thanks for having a look!

> Hi Jernej
> 
> On 1/3/21 6:26 PM, Jernej Skrabec wrote:
>> This PMIC can be found on H616 boards and it's very similar to AXP805
>> and AXP806.
> 
> Is there any plan to cleanup codes?

There is no support for either of these, we use the PMICs only in
Trusted Firmware or Linux. So nothing to consolidate, yet. This might
change in the future, and then of course we will use a common code base.

> 
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>>  arch/arm/mach-sunxi/pmic_bus.c |  6 +++
>>  board/sunxi/board.c| 10 +++--
>>  drivers/power/Kconfig  | 13 +-
>>  drivers/power/Makefile |  1 +
>>  drivers/power/axp305.c | 80 ++
>>  include/axp305.h   | 17 
>>  include/axp_pmic.h |  3 ++
>>  7 files changed, 126 insertions(+), 4 deletions(-)
>>  create mode 100644 drivers/power/axp305.c
>>  create mode 100644 include/axp305.h
>>
>> diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
>> index dea42de833f1..0394ce856448 100644
>> --- a/arch/arm/mach-sunxi/pmic_bus.c
>> +++ b/arch/arm/mach-sunxi/pmic_bus.c
>> @@ -18,6 +18,8 @@
>>  
>>  #define AXP209_I2C_ADDR 0x34
>>  
>> +#define AXP305_I2C_ADDR 0x36
>> +
>>  #define AXP221_CHIP_ADDR0x68
>>  #define AXP221_CTRL_ADDR0x3e
>>  #define AXP221_INIT_DATA0x3e
>> @@ -64,6 +66,8 @@ int pmic_bus_read(u8 reg, u8 *data)
>>  return i2c_read(AXP152_I2C_ADDR, reg, 1, data, 1);
>>  #elif defined CONFIG_AXP209_POWER
>>  return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
>> +#elif defined CONFIG_AXP305_POWER
>> +return i2c_read(AXP305_I2C_ADDR, reg, 1, data, 1);
>>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
>> CONFIG_AXP818_POWER
>>  # ifdef CONFIG_MACH_SUN6I
>>  return p2wi_read(reg, data);
>> @@ -81,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data)
>>  return i2c_write(AXP152_I2C_ADDR, reg, 1, , 1);
>>  #elif defined CONFIG_AXP209_POWER
>>  return i2c_write(AXP209_I2C_ADDR, reg, 1, , 1);
>> +#elif defined CONFIG_AXP305_POWER
>> +return i2c_write(AXP305_I2C_ADDR, reg, 1, , 1);
>>  #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
>> CONFIG_AXP818_POWER
>>  # ifdef CONFIG_MACH_SUN6I
>>  return p2wi_write(reg, data);
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index 708a27ed78e9..54ff9bc92396 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -634,16 +634,18 @@ void sunxi_board_init(void)
>>  #endif
>>  
>>  #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
>> -defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
>> -defined CONFIG_AXP818_POWER
>> +defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
>> +defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
>>  power_failed = axp_init();
>>  
>>  #if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
>>  defined CONFIG_AXP818_POWER
>>  power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
>>  #endif
>> +#if !defined(CONFIG_AXP305_POWER)
>>  power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
>>  power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
>> +#endif
>>  #if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
>>  power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
>>  #endif
>> @@ -656,8 +658,10 @@ void sunxi_board_init(void)
>>  defined CONFIG_AXP818_POWER
>>  power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
>>  #endif
>> +#if !defined(CONFIG_AXP305_POWER)
>>  power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
>> -#if !defined(CONFIG_AXP152_POWER)
>> +#endif
>> +#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
>>  power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
>>  #endif
>>  #ifdef CONFIG_AXP209_POWER
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index 02050f6f3569..d17cf2d9112a 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -48,6 +48,15 @@ config AXP221_POWER
>>  Select this to enable support for the axp221/axp223 pmic found on most
>>  A23 and A31 boards.
>>  
>> +config AXP305_POWER
>> +bool "axp305 pmic support"
>> +depends on MACH_SUN50I_H616
>> +select AXP_PMIC_BUS
>> +select CMD_POWEROFF
>> +---help---
>> +Select this to enable support for the axp305 pmic found on most
>> +H616 boards.
>> +
>>  config AXP809_POWER
>>  bool "axp809 pmic support"
>>  depends on MACH_SUN9I
>> @@ -127,11 +136,12 @@ config AXP_DCDC3_VOLT
>>  
>>  config AXP_DCDC4_VOLT
>>  int "axp pmic dcdc4 voltage"
>> -depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP818_POWER
>> +depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP818_POWER 
>> || AXP305_POWER
>>  

Re: [linux-sunxi] [PATCH 02/17] sunxi: Introduce common symbol for H6 like SoCs

[André Przywara]

On 03/01/2021 23:43, Samuel Holland wrote:

Hi Jernej,

thanks for that patch, that's a nice solution to avoid those long #ifdef
chains!

> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
>> It turns out that there are at least 2 other SoCs which have basically
>> the same memory map, similar clocks and other features as H6. It's very
>> likely that we'll see more such SoCs in the future. In order to ease
>> porting to new SoCs and lower ifdef clutter, introduce common symbol for
>> them.
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>>  arch/arm/include/asm/arch-sunxi/boot0.h |  2 +-
>>  arch/arm/include/asm/arch-sunxi/clock.h |  2 +-
>>  arch/arm/include/asm/arch-sunxi/cpu.h   |  2 +-
>>  arch/arm/include/asm/arch-sunxi/timer.h |  2 +-
>>  arch/arm/mach-sunxi/Kconfig | 21 +
>>  arch/arm/mach-sunxi/Makefile|  2 +-
>>  arch/arm/mach-sunxi/board.c |  4 ++--
>>  arch/arm/mach-sunxi/rmr_switch.S|  2 +-
>>  common/spl/Kconfig  |  4 ++--
>>  include/configs/sun50i.h|  2 +-
>>  10 files changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
>> b/arch/arm/include/asm/arch-sunxi/boot0.h
>> index 46d0f0666c2b..e8e8e38f0556 100644
>> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
>> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
>> @@ -39,7 +39,7 @@
>>  .word   0xf57ff06f  // isb sy
>>  .word   0xe320f003  // wfi
>>  .word   0xeafd  // b   @wfi
>> -#ifndef CONFIG_MACH_SUN50I_H6
>> +#ifndef CONFIG_SUN50I_GEN_H6
>>  .word   0x017000a0  // writeable RVBAR mapping address
>>  #else
>>  .word   0x09010040  // writeable RVBAR mapping address
>> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
>> b/arch/arm/include/asm/arch-sunxi/clock.h
>> index 5994130e6b54..cbbe5c7a1e68 100644
>> --- a/arch/arm/include/asm/arch-sunxi/clock.h
>> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
>> @@ -16,7 +16,7 @@
>>  /* clock control module regs definition */
>>  #if defined(CONFIG_MACH_SUN8I_A83T)
>>  #include 
>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>>  #include 
>>  #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
>>defined(CONFIG_MACH_SUN50I)
>> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
>> b/arch/arm/include/asm/arch-sunxi/cpu.h
>> index 8b57d24e2f0c..b08f2023748c 100644
>> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
>> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
>> @@ -8,7 +8,7 @@
>>  
>>  #if defined(CONFIG_MACH_SUN9I)
>>  #include 
>> -#elif defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUN50I_GEN_H6)
>>  #include 
>>  #else
>>  #include 
>> diff --git a/arch/arm/include/asm/arch-sunxi/timer.h 
>> b/arch/arm/include/asm/arch-sunxi/timer.h
>> index 6f138d04b806..bb5626d893bb 100644
>> --- a/arch/arm/include/asm/arch-sunxi/timer.h
>> +++ b/arch/arm/include/asm/arch-sunxi/timer.h
>> @@ -76,7 +76,7 @@ struct sunxi_timer_reg {
>>  struct sunxi_tgp tgp[4];
>>  u8 res5[8];
>>  u32 cpu_cfg;
>> -#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
>> +#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
>>  u8 res3[16];
>>  struct sunxi_wdog wdog[5];  /* We have 5 watchdogs */
>>  #endif
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 49ef217f08c0..1cf79bad7cf6 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -82,7 +82,7 @@ config SUN8I_RSB
>>  config SUNXI_SRAM_ADDRESS
>>  hex
>>  default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
>> -default 0x2 if MACH_SUN50I_H6
>> +default 0x2 if SUN50I_GEN_H6
>>  default 0x0
>>  ---help---
>>  Older Allwinner SoCs have their mask boot ROM mapped just below 4GB,
>> @@ -108,6 +108,15 @@ config SUNXI_GEN_SUN6I
>>  separate ahb reset control registers, custom pmic bus, new style
>>  watchdog, etc.
>>  
>> +config SUN50I_GEN_H6
> 
> The new memory map is also used for 32-bit SoCs V5 (sun8iw12p1) and
> newer. So this is not sun50i-specific, and I'd suggest SUNXI_GEN_H6 (or
> even SUNXI_GEN_H6_V5). It is unfortunate there appears to be no name for
> this family.

Yeah, the Allwinner generation naming being *core* dependent is really
annyoing and not helpful.
I am fine with a rename, but then it would be very close to
"CONFIG_SUNXI_GEN_SUN6I", which is quite confusing to any readers
(already stumbled upon it myself in patch 04/17).

Any opinions?

> 
>> +bool
>> +select FIT
>> +select SPL_LOAD_FIT
>> +select SUPPORT_SPL
>> +---help---
>> +Select this for sunxi SoCs which have H6 like peripherals, clocks
>> +and memory map.
>> +
>>  config SUNXI_DRAM_DW
>>  bool
>>  ---help---
>> @@ -302,10 +311,7 @@ config MACH_SUN50I_H5
>>  config MACH_SUN50I_H6
>>  bool "sun50i (Allwinner H6)"
>>  select ARM64
>> -

Re: [PATCH v2 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 23/12/2020 12:29, Amit Tomar wrote:
> Hi,
> 
> Thanks again for the detailed review
> 
> +
> 
> >  3 files changed, 407 insertions(+)
> >  create mode 100644 drivers/mmc/owl_mmc.c
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> > index 14d7913..61f9c67 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -289,6 +289,13 @@ config MMC_MXC
> > 
> >         If unsure, say N.
> > 
> > +config MMC_OWL
> > +     bool "Actions OWL Multimedia Card Interface support"
> > +     depends on ARCH_OWL && DM_MMC && BLK
> > +     help
> > +       This selects the OWL SD/MMC host controller found on board
> > +       based on Actions S700 SoC.
> 
> And S900 as well?
> 
> But as you aware S900 has different DMA requirements, would it be
> okay to claim that this works for S900 as well ?

Well, you tell me! At the moment I don't see much preventing people from
enabling it on the S900, and your compatible string listing in the
driver includes the S900 one.

What are the different DMA requirements? Aren't the controllers the same
as far as we are concerned, for the purpose of MMC?
And even if not, how much would it take to adapt the code?

Cheers,
Andre

> 
> > +
> >  config MMC_MXS
> >       bool "Freescale MXS Multimedia Card Interface support"
> >       depends on MX23 || MX28 || MX6 || MX7
> > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> > index 1c849cb..f270f6c 100644
> > --- a/drivers/mmc/Makefile
> > +++ b/drivers/mmc/Makefile
> > @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)           += omap_hsmmc.o
> >  obj-$(CONFIG_MMC_MXC)                        += mxcmmc.o
> >  obj-$(CONFIG_MMC_MXS)                        += mxsmmc.o
> >  obj-$(CONFIG_MMC_OCTEONTX)           += octeontx_hsmmc.o
> > +obj-$(CONFIG_MMC_OWL)                        += owl_mmc.o
> >  obj-$(CONFIG_MMC_PCI)                        += pci_mmc.o
> >  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
> >  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
> > diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
> > new file mode 100644
> > index 000..5c48307
> > --- /dev/null
> > +++ b/drivers/mmc/owl_mmc.c
> > @@ -0,0 +1,399 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Amit Singh Tomar  >
> > + *
> > + * Driver for SD/MMC controller present on Actions Semi S700 SoC,
> based
> > + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
> > + *
> > + * Though, there is a bit (BSEL, BUS or DMA Special Channel
> Selection) that
> > + * controls the data transfer from SDx_DAT register either using
> CPU AHB Bus
> > + * or DMA channel, but seems like, it only works correctly using
> external DMA
> > + * channel, and those special bits used in this driver is picked
> from vendor
> > + * source exclusively for MMC/SD.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * SDC registers
> > + */
> > +#define OWL_REG_SD_EN                   0x
> > +#define OWL_REG_SD_CTL                  0x0004
> > +#define OWL_REG_SD_STATE                0x0008
> > +#define OWL_REG_SD_CMD                  0x000c
> > +#define OWL_REG_SD_ARG                  0x0010
> > +#define OWL_REG_SD_RSPBUF0              0x0014
> > +#define OWL_REG_SD_RSPBUF1              0x0018
> > +#define OWL_REG_SD_RSPBUF2              0x001c
> > +#define OWL_REG_SD_RSPBUF3              0x0020
> > +#define OWL_REG_SD_RSPBUF4              0x0024
> > +#define OWL_REG_SD_DAT                  0x0028
> > +#define OWL_REG_SD_BLK_SIZE             0x002c
> > +#define OWL_REG_SD_BLK_NUM              0x0030
> > +#define OWL_REG_SD_BUF_SIZE             0x0034
> > +
> > +/* SD_EN Bits */
> > +#define OWL_SD_EN_RANE                  BIT(31)
> > +#define OWL_SD_EN_RESE                  BIT(10)
> > +#define OWL_SD_ENABLE                   BIT(7)
> > +#define OWL_SD_EN_BSEL                  BIT(6)
> > +#define OWL_SD_EN_DATAWID(x)            (((x) & 0x3) << 0)
> > +#define OWL_SD_EN_DATAWID_MASK               0x03
> > +
> > +/* SD_CTL Bits */
> > +#define OWL_SD_CTL_TOUTEN               BIT(31)
> > +#define OWL_SD_CTL_DELAY_MSK            GENMASK(23, 16)
> > +#define OWL_SD_CTL_RDELAY(x)            (((x) & 0xf) << 20)
> > +#define OWL_SD_CTL_WDELAY(x)            (((x) & 0xf) << 16)
> > +#define OWL_SD_CTL_TS                   BIT(7)
> > +#define OWL_SD_CTL_LBE                  BIT(6)
> > 

Re: [PATCH v2 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 23/12/2020 04:25, Jaehoon Chung wrote:
> On 12/23/20 11:22 AM, Amit Tomer wrote:
>> On Wed, Dec 23, 2020 at 5:57 AM André Przywara  
>> wrote:
>>>
>>> On 19/12/2020 14:51, Amit Singh Tomar wrote:
>>>> From: Amit Singh Tomar 
>>>>
>>>> This commit adds support for MMC controllers found on Actions OWL
>>>> S700 SoC platform.
>>>>
>>>> Signed-off-by: Amit Singh Tomar 
>>>> ---
>>>> Changes since previous version
>>>>   * Corrected block count to 512.
>>>>   * Changed the command timeout value to 30ms.
>>>>   * Used readl_poll_timeout.
>>>>   * Read DMA parameters from DT instead of hardcoding it.
>>>>   * Reduced number of arguments passed to own_dma_cofig.
>>>>   * Removed debug leftover.
>>>>   * Used mmc_of_parse().
>>>> ---
>>>>  drivers/mmc/Kconfig   |   7 +
>>>>  drivers/mmc/Makefile  |   1 +
>>>>  drivers/mmc/owl_mmc.c | 399 
>>>> ++
>>>>  3 files changed, 407 insertions(+)
>>>>  create mode 100644 drivers/mmc/owl_mmc.c
>>>>
>>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>>> index 14d7913..61f9c67 100644
>>>> --- a/drivers/mmc/Kconfig
>>>> +++ b/drivers/mmc/Kconfig
>>>> @@ -289,6 +289,13 @@ config MMC_MXC
>>>>
>>>> If unsure, say N.
>>>>
>>>> +config MMC_OWL
>>>> + bool "Actions OWL Multimedia Card Interface support"
>>>> + depends on ARCH_OWL && DM_MMC && BLK
>>>> + help
>>>> +   This selects the OWL SD/MMC host controller found on board
>>>> +   based on Actions S700 SoC.
>>>
>>> And S900 as well?
>>>
>>>> +
>>>>  config MMC_MXS
>>>>   bool "Freescale MXS Multimedia Card Interface support"
>>>>   depends on MX23 || MX28 || MX6 || MX7
>>>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>>>> index 1c849cb..f270f6c 100644
>>>> --- a/drivers/mmc/Makefile
>>>> +++ b/drivers/mmc/Makefile
>>>> @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)   += omap_hsmmc.o
>>>>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>>>>  obj-$(CONFIG_MMC_MXS)+= mxsmmc.o
>>>>  obj-$(CONFIG_MMC_OCTEONTX)   += octeontx_hsmmc.o
>>>> +obj-$(CONFIG_MMC_OWL)+= owl_mmc.o
>>>>  obj-$(CONFIG_MMC_PCI)+= pci_mmc.o
>>>>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>>>>  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
>>>> diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
>>>> new file mode 100644
>>>> index 000..5c48307
>>>> --- /dev/null
>>>> +++ b/drivers/mmc/owl_mmc.c
>>>> @@ -0,0 +1,399 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Copyright (C) 2020 Amit Singh Tomar 
>>>> + *
>>>> + * Driver for SD/MMC controller present on Actions Semi S700 SoC, based
>>>> + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
>>>> + *
>>>> + * Though, there is a bit (BSEL, BUS or DMA Special Channel Selection) 
>>>> that
>>>> + * controls the data transfer from SDx_DAT register either using CPU AHB 
>>>> Bus
>>>> + * or DMA channel, but seems like, it only works correctly using external 
>>>> DMA
>>>> + * channel, and those special bits used in this driver is picked from 
>>>> vendor
>>>> + * source exclusively for MMC/SD.
>>>> + */
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +/*
>>>> + * SDC registers
>>>> + */
>>>> +#define OWL_REG_SD_EN   0x
>>>> +#define OWL_REG_SD_CTL  0x0004
>>>> +#define OWL_REG_SD_STATE0x0008
>>>> +#define OWL_REG_SD_CMD  0x000c
>>>> +#define OWL_REG_SD_ARG  0x0010
>>>&g

Re: [PATCH v2 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 19/12/2020 14:51, Amit Singh Tomar wrote:
> From: Amit Singh Tomar 
> 
> This commit adds support for MMC controllers found on Actions OWL
> S700 SoC platform.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since previous version
>   * Corrected block count to 512.
>   * Changed the command timeout value to 30ms.
>   * Used readl_poll_timeout. 
>   * Read DMA parameters from DT instead of hardcoding it.
>   * Reduced number of arguments passed to own_dma_cofig.
>   * Removed debug leftover.
>   * Used mmc_of_parse().
> ---
>  drivers/mmc/Kconfig   |   7 +
>  drivers/mmc/Makefile  |   1 +
>  drivers/mmc/owl_mmc.c | 399 
> ++
>  3 files changed, 407 insertions(+)
>  create mode 100644 drivers/mmc/owl_mmc.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 14d7913..61f9c67 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -289,6 +289,13 @@ config MMC_MXC
>  
> If unsure, say N.
>  
> +config MMC_OWL
> + bool "Actions OWL Multimedia Card Interface support"
> + depends on ARCH_OWL && DM_MMC && BLK
> + help
> +   This selects the OWL SD/MMC host controller found on board
> +   based on Actions S700 SoC.

And S900 as well?

> +
>  config MMC_MXS
>   bool "Freescale MXS Multimedia Card Interface support"
>   depends on MX23 || MX28 || MX6 || MX7
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 1c849cb..f270f6c 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)   += omap_hsmmc.o
>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>  obj-$(CONFIG_MMC_MXS)+= mxsmmc.o
>  obj-$(CONFIG_MMC_OCTEONTX)   += octeontx_hsmmc.o
> +obj-$(CONFIG_MMC_OWL)+= owl_mmc.o
>  obj-$(CONFIG_MMC_PCI)+= pci_mmc.o
>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
> diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
> new file mode 100644
> index 000..5c48307
> --- /dev/null
> +++ b/drivers/mmc/owl_mmc.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Amit Singh Tomar 
> + *
> + * Driver for SD/MMC controller present on Actions Semi S700 SoC, based
> + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
> + *
> + * Though, there is a bit (BSEL, BUS or DMA Special Channel Selection) that
> + * controls the data transfer from SDx_DAT register either using CPU AHB Bus
> + * or DMA channel, but seems like, it only works correctly using external DMA
> + * channel, and those special bits used in this driver is picked from vendor
> + * source exclusively for MMC/SD.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SDC registers
> + */
> +#define OWL_REG_SD_EN   0x
> +#define OWL_REG_SD_CTL  0x0004
> +#define OWL_REG_SD_STATE0x0008
> +#define OWL_REG_SD_CMD  0x000c
> +#define OWL_REG_SD_ARG  0x0010
> +#define OWL_REG_SD_RSPBUF0  0x0014
> +#define OWL_REG_SD_RSPBUF1  0x0018
> +#define OWL_REG_SD_RSPBUF2  0x001c
> +#define OWL_REG_SD_RSPBUF3  0x0020
> +#define OWL_REG_SD_RSPBUF4  0x0024
> +#define OWL_REG_SD_DAT  0x0028
> +#define OWL_REG_SD_BLK_SIZE 0x002c
> +#define OWL_REG_SD_BLK_NUM  0x0030
> +#define OWL_REG_SD_BUF_SIZE 0x0034
> +
> +/* SD_EN Bits */
> +#define OWL_SD_EN_RANE  BIT(31)
> +#define OWL_SD_EN_RESE  BIT(10)
> +#define OWL_SD_ENABLE   BIT(7)
> +#define OWL_SD_EN_BSEL  BIT(6)
> +#define OWL_SD_EN_DATAWID(x)(((x) & 0x3) << 0)
> +#define OWL_SD_EN_DATAWID_MASK   0x03
> +
> +/* SD_CTL Bits */
> +#define OWL_SD_CTL_TOUTEN   BIT(31)
> +#define OWL_SD_CTL_DELAY_MSKGENMASK(23, 16)
> +#define OWL_SD_CTL_RDELAY(x)(((x) & 0xf) << 20)
> +#define OWL_SD_CTL_WDELAY(x)(((x) & 0xf) << 16)
> +#define OWL_SD_CTL_TS   BIT(7)
> +#define OWL_SD_CTL_LBE  BIT(6)
> +#define OWL_SD_CTL_TM(x)(((x) & 0xf) << 0)
> +
> +#define OWL_SD_DELAY_LOW_CLK0x0f
> +#define OWL_SD_DELAY_MID_CLK0x0a
> +#define OWL_SD_RDELAY_HIGH   0x08
> +#define OWL_SD_WDELAY_HIGH   0x09

w/s? Here and elsewhere. I would use tabs everywhere instead.

> +
> +/* SD_STATE Bits */
> +#define OWL_SD_STATE_DAT0S  BIT(7)
> +#define OWL_SD_STATE_CLNR   BIT(4)
> +#define OWL_SD_STATE_CRC7ER BIT(0)
> +
> +#define OWL_MMC_OCR (MMC_VDD_32_33 | MMC_VDD_33_34 | \
> +  

Re: [PATCH v2 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 22/12/2020 23:37, Jaehoon Chung wrote:
> On 12/19/20 11:51 PM, Amit Singh Tomar wrote:
>> From: Amit Singh Tomar 
>>
>> This commit adds support for MMC controllers found on Actions OWL
>> S700 SoC platform.
>>
>> Signed-off-by: Amit Singh Tomar 
>> ---
>> Changes since previous version
>>  * Corrected block count to 512.
>>  * Changed the command timeout value to 30ms.
>>  * Used readl_poll_timeout. 
>>  * Read DMA parameters from DT instead of hardcoding it.
>>  * Reduced number of arguments passed to own_dma_cofig.
>>  * Removed debug leftover.
>>  * Used mmc_of_parse().
>> ---
>>  drivers/mmc/Kconfig   |   7 +
>>  drivers/mmc/Makefile  |   1 +
>>  drivers/mmc/owl_mmc.c | 399 
>> ++
>>  3 files changed, 407 insertions(+)
>>  create mode 100644 drivers/mmc/owl_mmc.c
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index 14d7913..61f9c67 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -289,6 +289,13 @@ config MMC_MXC
>>  
>>If unsure, say N.
>>  
>> +config MMC_OWL
>> +bool "Actions OWL Multimedia Card Interface support"
>> +depends on ARCH_OWL && DM_MMC && BLK
>> +help
>> +  This selects the OWL SD/MMC host controller found on board
>> +  based on Actions S700 SoC.
>> +
>>  config MMC_MXS
>>  bool "Freescale MXS Multimedia Card Interface support"
>>  depends on MX23 || MX28 || MX6 || MX7
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index 1c849cb..f270f6c 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)  += omap_hsmmc.o
>>  obj-$(CONFIG_MMC_MXC)   += mxcmmc.o
>>  obj-$(CONFIG_MMC_MXS)   += mxsmmc.o
>>  obj-$(CONFIG_MMC_OCTEONTX)  += octeontx_hsmmc.o
>> +obj-$(CONFIG_MMC_OWL)   += owl_mmc.o
>>  obj-$(CONFIG_MMC_PCI)   += pci_mmc.o
>>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>>  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
>> diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
>> new file mode 100644
>> index 000..5c48307
>> --- /dev/null
>> +++ b/drivers/mmc/owl_mmc.c
>> @@ -0,0 +1,399 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2020 Amit Singh Tomar 
>> + *
>> + * Driver for SD/MMC controller present on Actions Semi S700 SoC, based
>> + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
>> + *
>> + * Though, there is a bit (BSEL, BUS or DMA Special Channel Selection) that
>> + * controls the data transfer from SDx_DAT register either using CPU AHB Bus
>> + * or DMA channel, but seems like, it only works correctly using external 
>> DMA
>> + * channel, and those special bits used in this driver is picked from vendor
>> + * source exclusively for MMC/SD.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * SDC registers
>> + */
>> +#define OWL_REG_SD_EN   0x
>> +#define OWL_REG_SD_CTL  0x0004
>> +#define OWL_REG_SD_STATE0x0008
>> +#define OWL_REG_SD_CMD  0x000c
>> +#define OWL_REG_SD_ARG  0x0010
>> +#define OWL_REG_SD_RSPBUF0  0x0014
>> +#define OWL_REG_SD_RSPBUF1  0x0018
>> +#define OWL_REG_SD_RSPBUF2  0x001c
>> +#define OWL_REG_SD_RSPBUF3  0x0020
>> +#define OWL_REG_SD_RSPBUF4  0x0024
>> +#define OWL_REG_SD_DAT  0x0028
>> +#define OWL_REG_SD_BLK_SIZE 0x002c
>> +#define OWL_REG_SD_BLK_NUM  0x0030
>> +#define OWL_REG_SD_BUF_SIZE 0x0034
>> +
>> +/* SD_EN Bits */
>> +#define OWL_SD_EN_RANE  BIT(31)
>> +#define OWL_SD_EN_RESE  BIT(10)
>> +#define OWL_SD_ENABLE   BIT(7)
>> +#define OWL_SD_EN_BSEL  BIT(6)
>> +#define OWL_SD_EN_DATAWID(x)(((x) & 0x3) << 0)
>> +#define OWL_SD_EN_DATAWID_MASK  0x03
>> +
>> +/* SD_CTL Bits */
>> +#define OWL_SD_CTL_TOUTEN   BIT(31)
>> +#define OWL_SD_CTL_DELAY_MSKGENMASK(23, 16)
>> +#define OWL_SD_CTL_RDELAY(x)(((x) & 0xf) << 20)
>> +#define OWL_SD_CTL_WDELAY(x)(((x) & 0xf) << 16)
>> +#define OWL_SD_CTL_TS   BIT(7)
>> +#define OWL_SD_CTL_LBE  BIT(6)
>> +#define OWL_SD_CTL_TM(x)(((x) & 0xf) << 0)
>> +
>> +#define OWL_SD_DELAY_LOW_CLK0x0f
>> +#define OWL_SD_DELAY_MID_CLK0x0a
>> +#define OWL_SD_RDELAY_HIGH  0x08
>> +#define OWL_SD_WDELAY_HIGH  0x09
>> +
>> +/* SD_STATE Bits */
>> +#define OWL_SD_STATE_DAT0S  BIT(7)
>> +#define OWL_SD_STATE_CLNR   BIT(4)
>> +#define OWL_SD_STATE_CRC7ER BIT(0)
>> +
>> +#define OWL_MMC_OCR

Re: [PATCH v2 4/6] ARM: dts: s700: add MMC/SD controller node

[André Przywara]

On 22/12/2020 23:28, Jaehoon Chung wrote:
> On 12/19/20 11:51 PM, Amit Singh Tomar wrote:
>> From: Amit Singh Tomar 
>>
>> This patch adds node for ethernet controller found on Action Semi OWL
>> S700 SoC.
> 
> Is "ethernet controller" right?
> 
>>
>> Since, upstream Linux binding has not been merged for S700 MMC/SD
>> controller, Changes are put in u-boot specific dtsi file.
>>
>> Signed-off-by: Amit Singh Tomar 
>> ---
>> Changes since previous version
>>  * No change.
>> ---
>>  arch/arm/dts/s700-u-boot.dtsi | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
>> index 1b27682..3c3396b 100644
>> --- a/arch/arm/dts/s700-u-boot.dtsi
>> +++ b/arch/arm/dts/s700-u-boot.dtsi
>> @@ -19,6 +19,16 @@
>>  status = "okay";
>>  };
>>  
>> +mmc0: mmc@e021 {
>> +compatible = "actions,s700-mmc", "actions,owl-mmc";
> 
> Not need to add both..

We *do* need to have both:
a) it's good style to list "chip-specific", "generic-compatible-model"
for a certain SoC. This allows to later cover bugs or enhancements
without changing the DT.
b) it's what Linux will get
c) it's already the documented binding:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/owl-mmc.yaml

Cheers,
Andre

> 
>> +reg = <0x0 0xe021 0x0 0x4000>;
>> +interrupts = ;
>> +clocks = < CLK_SD0>;
>> +dmas = < 2>;
>> +dma-names = "mmc";
>> +bus-width = <4>;
>> +status = "okay";
>> +};
>>  };
>>  };
>>  
>>
> 

Re: [PATCH v2 2/6] clk: actions: Add SD/MMC clocks

[André Przywara]

On 19/12/2020 14:51, Amit Singh Tomar wrote:

Hi,

> From: Amit Singh Tomar 
> 
> This commit adds SD/MMC clocks, and provides .set/get_rate callbacks
> for SD/MMC device present on Actions OWL S700 SoCs.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since previous version:
>   * Removed rate *= 2 as this just overclocks.
>   * Separated the divide by 128 bit from divider value.
>   * Provided the separate routine to get sd parent rate
> based on bit 9.   
>   * Removed unnecessary initialization.
> ---
>  drivers/clk/owl/clk_owl.c | 72 
> +++
>  drivers/clk/owl/clk_owl.h |  2 ++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/drivers/clk/owl/clk_owl.c b/drivers/clk/owl/clk_owl.c
> index 5be1b3b..cac8e6e 100644
> --- a/drivers/clk/owl/clk_owl.c
> +++ b/drivers/clk/owl/clk_owl.c
> @@ -92,6 +92,9 @@ int owl_clk_enable(struct clk *clk)
>   setbits_le32(priv->base + CMU_DEVCLKEN1, CMU_DEVCLKEN1_ETH);
>   setbits_le32(priv->base + CMU_ETHERNETPLL, 5);
>   break;
> + case CLK_SD0:
> + setbits_le32(priv->base + CMU_DEVCLKEN0, CMU_DEVCLKEN0_SD0);
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -121,6 +124,9 @@ int owl_clk_disable(struct clk *clk)
>   case CLK_ETHERNET:
>   clrbits_le32(priv->base + CMU_DEVCLKEN1, CMU_DEVCLKEN1_ETH);
>   break;
> + case CLK_SD0:
> + clrbits_le32(priv->base + CMU_DEVCLKEN0, CMU_DEVCLKEN0_SD0);
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -128,11 +134,73 @@ int owl_clk_disable(struct clk *clk)
>   return 0;
>  }
>  
> +static ulong get_sd_parent_rate(struct owl_clk_priv *priv, u32 dev_index)
> +{
> + ulong rate;
> + u32 reg;
> +
> + reg = readl(priv->base + (CMU_SD0CLK + dev_index * 0x4));
> + /* Clock output of DEV/NAND_PLL
> +  * Range: 48M ~ 756M
> +  * Frequency= PLLCLK * 6
> +  */
> + if (reg & 0x200)
> + rate = readl(priv->base + CMU_NANDPLL) & 0x7f;
> + else
> + rate = readl(priv->base + CMU_DEVPLL) & 0x7f;
> +
> + rate *= 600;
> +
> + return rate;
> +}
> +
> +static ulong owl_get_sd_clk_rate(struct owl_clk_priv *priv, int sd_index)
> +{
> + uint div;
> + ulong parent_rate = get_sd_parent_rate(priv, sd_index);
> +
> + div = readl(priv->base + (CMU_SD0CLK + sd_index * 0x4)) & 0x1f;
> + div++;

That looks weird. Either add it directly above or below.

> +
> + return (parent_rate / div);
> +}
> +
> +static ulong owl_set_sd_clk_rate(struct owl_clk_priv *priv, ulong rate,
> +  int sd_index)
> +{
> + uint div, val;
> + ulong parent_rate = get_sd_parent_rate(priv, sd_index);
> +
> + if (rate <= 0)

rate is unsigned, so the "< 0" part is not needed.

> + return rate;
> +
> + div = (parent_rate / rate);
> +
> + val = readl(priv->base + (CMU_SD0CLK + sd_index * 0x4));
> + /* Bits 4..0 is used to program div value and bit 8 to enable
> +  * divide by 128 circuit
> +  */
> + val &= ~0x11f;
> + if (div >= 128) {
> + div = div / 128;
> + val |= 0x100; /* enable divide by 128 circuit */
> + }
> + div--;

That looks weird. It's a encoding thing, so just subtract the "1"
directly below.

> + val |= (div & 0x1f);
> + writel(val, priv->base + (CMU_SD0CLK + sd_index * 0x4));
> +
> + return owl_get_sd_clk_rate(priv, 0);
> +}
> +
>  static ulong owl_clk_get_rate(struct clk *clk)
>  {
> + struct owl_clk_priv *priv = dev_get_priv(clk->dev);
>   ulong rate;
>  
>   switch (clk->id) {
> + case CLK_SD0:
> + rate = owl_get_sd_clk_rate(priv, 0);
> + break;
>   default:
>   return -ENOENT;
>   }
> @@ -142,9 +210,13 @@ static ulong owl_clk_get_rate(struct clk *clk)
>  
>  static ulong owl_clk_set_rate(struct clk *clk, ulong rate)
>  {
> + struct owl_clk_priv *priv = dev_get_priv(clk->dev);
>   ulong new_rate;
>  
>   switch (clk->id) {
> + case CLK_SD0:
> + new_rate = owl_set_sd_clk_rate(priv, rate, 0);
> + break;
>   default:
>   return -ENOENT;
>   }
> diff --git a/drivers/clk/owl/clk_owl.h b/drivers/clk/owl/clk_owl.h
> index a01f81a..ee5eba4 100644
> --- a/drivers/clk/owl/clk_owl.h
> +++ b/drivers/clk/owl/clk_owl.h
> @@ -62,4 +62,6 @@ struct owl_clk_priv {
>  #define CMU_DEVCLKEN1_UART5  BIT(21)
>  #define CMU_DEVCLKEN1_UART3  BIT(11)
>  
> +#define CMU_DEVCLKEN0_SD0BIT(22)
> +

Why do we actually have those values in a header file? The driver is
supposed to abstract from them, so there should be no need to have those
values shared in an include file? I guess clk_owl.c is the only user?

Cheers,
Andre

Re: [PATCH 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 14/12/2020 15:02, Amit Tomar wrote:
> Hi,
> 
> You could pass a pointer to owl_mmc_priv here, which can hold both those
> 
> values. See below for more more on this.
> 
> Did you mean for argument 3rd and 4th but then in that case how one
> could have differentiated
> between source and destination.
> 
> for instance 3rd and 4th arguments are different for read and write flag.

No, just the first two arguments (that's why I put the comment after
this line).

> 
> 
> > +             unsigned int src, unsigned int dst,
> > +             unsigned int len)
> > +{
> > +     unsigned int mode = drq;
> > +     u8 frame_cnt = 0x1;
> 
> Not needed, just use the 0x1 below directly.
> 
> 
> Ok.
> 
> 
> > +
> > +     /* Set Source and Destination adderess mode */
> > +     mode |= (DMA_MODE_ST_DEV | DMA_MODE_SAM_CONST |
> DMA_MODE_DT_DCU |
> > +                     DMA_MODE_DAM_INC);
> > +
> > +     writel(mode, dma_base + DMA_MODE);
> > +     writel(src, dma_base + DMA_SOURCE);
> > +     writel(dst, dma_base + DMA_DESTINATION);
> > +     writel(len, dma_base + DMA_FRAME_LEN);
> > +     writel(frame_cnt, dma_base + DMA_FRAME_CNT);
> > +}
> > +
> > +static void owl_mmc_prepare_data(struct owl_mmc_priv *priv,
> > +             struct mmc_data *data)
> > +{
> > +     unsigned int reg, total;
> > +     uint32_t buf = 0;
> > +
> > +     reg = readl(priv->reg_base + OWL_REG_SD_EN);
> > +     reg |= OWL_SD_EN_BSEL;
> > +     writel(reg, priv->reg_base + OWL_REG_SD_EN);
> > +
> > +     writel(data->blocks, priv->reg_base + OWL_REG_SD_BLK_NUM);
> > +     writel(data->blocksize, priv->reg_base + OWL_REG_SD_BLK_SIZE);
> > +     total = data->blocksize * data->blocks;
> > +
> > +     if (data->blocksize < 512)
> > +             writel(total, priv->reg_base + OWL_REG_SD_BUF_SIZE);
> > +     else
> > +             writel(512, priv->reg_base + OWL_REG_SD_BUF_SIZE);
> > +
> > +     /* DMA STOP */
> > +     writel(0x0, (DMA0_CHANNEL_BASE(2) + DMA_START));
> > +
> > +     if (data) {
> > +             if (data->flags == MMC_DATA_READ) {
> 
> Shouldn't that be used with '&', since it's one flag among others?
> 
> 
> ,Actually, I wasn't sure about some driver uses == and other one &, even
> here in Mainline
> U-boot.

Well, flags somewhat suggests it's a bitmap, but indeed mmc.c just
assigns a value, and "1" and "2" would work in both ways.

> > +                     buf = (ulong) (data->dest);
> > +                     owl_dma_config((void *) DMA0_CHANNEL_BASE(2),
> > +                                     priv->dma_drq,
> > +                                     (ulong) priv->reg_base +
> > +                                     OWL_REG_SD_DAT,
> > +                                     buf, total);
> > +                     invalidate_dcache_range(buf, buf + total);
> > +             } else if (data->flags == MMC_DATA_WRITE) {
> > +                     buf = (ulong) (data->src);
> > +                     owl_dma_config((void *) DMA0_CHANNEL_BASE(2),
> > +                                     priv->dma_drq,
> > +                                     buf,
> > +                                     (ulong) priv->reg_base +
> > +                                     OWL_REG_SD_DAT,
> > +                                     total);
> > +                     flush_dcache_range(buf, buf + total);
> > +             }
> > +             /* DMA START */
> > +             writel(0x1, (DMA0_CHANNEL_BASE(2) + DMA_START));
> > +     }
> > +}
> > +
> > +static int owl_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
> > +             struct mmc_data *data)
> > +{
> > +     struct owl_mmc_priv *priv = dev_get_priv(dev);
> > +     unsigned int cmd_rsp_mask, mode, reg;
> > +     int timeout = DATA_TRANSFER_TIMEOUT;
> > +
> > +     reg = readl(priv->reg_base + OWL_REG_SD_EN);
> > +     reg |= OWL_SD_ENABLE;
> > +     writel(reg, priv->reg_base + OWL_REG_SD_EN);
> > +
> > +     /* setup response */
> > +     switch (cmd->resp_type) {
> > +     case MMC_RSP_NONE:
> > +             break;
> > +     case MMC_RSP_R1:
> > +             if (data) {
> > +                     if (data->flags == MMC_DATA_READ)
> > +                             mode = OWL_SD_CTL_TM(4);
> > +                     else
> > +                             mode = OWL_SD_CTL_TM(5);
> > +             } else {
> > +                     mode = OWL_SD_CTL_TM(1);
> > +             }
> > +             cmd_rsp_mask = OWL_SD_STATE_CLNR | OWL_SD_STATE_CRC7ER;
> > +             break;
> > +     case MMC_RSP_R1b:
> > +             mode = OWL_SD_CTL_TM(3);
> > +             cmd_rsp_mask = OWL_SD_STATE_CLNR | 

Re: [PATCH 2/6] clk: actions: Add SD/MMC clocks

[André Przywara]

On 14/12/2020 14:12, Amit Tomer wrote:
> Hi,
> 
> Thanks for having the detailed look and providing comments:
> 
>> According to the datasheet the clock source could also be NAND_PLL,
>> depending on bit 9.
>> Both PLLs use the same rate calculation, so it's just matter of the PLL
>> address offset to use for covering both.
> 
> Ok, should I change the comment as Clock output of DEV/NAND_PLL ?

I meant you should read the parent rate either from the NAND or the DEV
PLL, depending on this bit.
Since you force the parent to be DEV that's not strictly needed for this
current use case, but it's much cleaner to do so in the *clock* driver,
and as I said, is not hard to do.

> 
>>> +
>>> + /* Clock output of DEV_PLL
>>> +  * Range: 48M ~ 756M
>>> +  * Frequency= DEVPLLCLK * 6
>>> +  */
>>> + parent_rate = readl(priv->base + CMU_DEVPLL) & 0x7f;
>>> + parent_rate *= 600;
>>> +
>>> + rate *= 2;
>>
>> Where does this come from?
> 
> While experimenting about it, I found that doubling input rate doubles the
> speed , and BSP code does the same.

Sure doubling the input frequency improves the performance, but is also
wrong. If the card can do twice as much *reliably*, then it would
advertise more advanced speed modes, and we could use them. Otherwise
it's just overclocking.
You should check what the card reports (SDR50?), then check which clock
value you set, and what the performance is (for reading a bigger number
of sectors). If that matches up (SDR50 => 50 MHz => ~25MB/s), then it's
correct. Everything else should be investigated.

> Not sure if it is a good enough explanation or maybe its side effect of not
> programming divider value well when its >=128. Would check it again.

This explanation sounds very dodgy. There might be a hidden divider
somewhere, but this should be discoverable by the test I described above.
And since the "divide-by-128" is only needed for the initial 400KHz
communication, I don't think it's related here.

> 
>>> + div = (parent_rate / rate) - 1;
>>
>> Please check rate being not zero before you dividing by it. And I would
>> keep the real divider value for now, so drop the -1 here.
> 
> Ok. I would make the check.
> 
>>> +
>>> + if (div >= 128)
>>> + div |= 0x100;
>>
>> This does not seem right. You would need to divide the value by 128,
>> once you decided to use the "divide-by-128" bit (which is bit 8).
>> What about moving this below, after you know the register value?
>> Then you can divide by 128 and set bit 8.
> 
> Sure, Thanks for explaining it in detail. It helped understanding
> ACTIONS not so usual
> clock design.
> 
>>> + val = readl(priv->base + (CMU_SD0CLK + sd_index*0x4));
>>> + /* Bits 4..0 is used to program div value */
>>> + val &= ~0x1f;
>>> + val |= div;
>>
>> Please mask div before applying.
> 
> But I am masking the first 4.0 bit above , ~0x1f;

No, you are masking val, not div. If div is bigger than 31, you set
other bits in this register.

>>> + /* As per Manuals Bits 31..10 are reserved but Bits 11 and
>>> +  * 10 needed to be set for proper operation
>>> +  */
>>> + val |= 0xc00;
>>
>> Where does this come from? I don't see the Linux driver doing that?
> 
> Actually if I don't set 11th and 10th bit , I see SD speed of 2KiB/s
> and unstable behaviour
> while loading files from the card.
> BSP U-boot driver chooses a value 0xfce0 for it.

I wouldn't rely on downstream BSP U-Boot for *anything*.
I guess you see normal speed in (almost) mainline Linux? Check what we
do with the clock register there (can dump it once the driver has
initialised).
I would rather mimic the mainline kernel here than anything else.

Cheers,
Andre

Re: [PATCH 5/6] mmc: actions: add MMC driver for Actions OWL S700

[André Przywara]

On 13/12/2020 10:08, Amit Singh Tomar wrote:
> From: Amit Singh Tomar 
> 
> This commit adds support for MMC controllers found on Actions OWL
> S700 SoC platform.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  drivers/mmc/Kconfig   |   7 +
>  drivers/mmc/Makefile  |   1 +
>  drivers/mmc/owl_mmc.c | 404 
> ++
>  3 files changed, 412 insertions(+)
>  create mode 100644 drivers/mmc/owl_mmc.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 14d7913..61f9c67 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -289,6 +289,13 @@ config MMC_MXC
>  
> If unsure, say N.
>  
> +config MMC_OWL
> + bool "Actions OWL Multimedia Card Interface support"
> + depends on ARCH_OWL && DM_MMC && BLK
> + help
> +   This selects the OWL SD/MMC host controller found on board
> +   based on Actions S700 SoC.
> +
>  config MMC_MXS
>   bool "Freescale MXS Multimedia Card Interface support"
>   depends on MX23 || MX28 || MX6 || MX7
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 1c849cb..f270f6c 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_OMAP_HS)   += omap_hsmmc.o
>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>  obj-$(CONFIG_MMC_MXS)+= mxsmmc.o
>  obj-$(CONFIG_MMC_OCTEONTX)   += octeontx_hsmmc.o
> +obj-$(CONFIG_MMC_OWL)+= owl_mmc.o
>  obj-$(CONFIG_MMC_PCI)+= pci_mmc.o
>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>  obj-$(CONFIG_$(SPL_TPL_)SUPPORT_EMMC_RPMB) += rpmb.o
> diff --git a/drivers/mmc/owl_mmc.c b/drivers/mmc/owl_mmc.c
> new file mode 100644
> index 000..aa0ccb7
> --- /dev/null
> +++ b/drivers/mmc/owl_mmc.c
> @@ -0,0 +1,404 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Amit Singh Tomar 
> + *
> + * Driver for SD/MMC controller present on Actions Semi S700 SoC, based
> + * on Linux Driver "drivers/mmc/host/owl-mmc.c".
> + *
> + * Though, there is a bit (BSEL, BUS or DMA Special Channel Selection) that
> + * controls the data transfer from SDx_DAT register either using CPU AHB Bus
> + * or DMA channel, but seems like, it only works correctly using external DMA
> + * channel, and those special bits used in this driver is picked from vendor
> + * source exclusively for MMC/SD.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SDC registers
> + */
> +#define OWL_REG_SD_EN   0x
> +#define OWL_REG_SD_CTL  0x0004
> +#define OWL_REG_SD_STATE0x0008
> +#define OWL_REG_SD_CMD  0x000c
> +#define OWL_REG_SD_ARG  0x0010
> +#define OWL_REG_SD_RSPBUF0  0x0014
> +#define OWL_REG_SD_RSPBUF1  0x0018
> +#define OWL_REG_SD_RSPBUF2  0x001c
> +#define OWL_REG_SD_RSPBUF3  0x0020
> +#define OWL_REG_SD_RSPBUF4  0x0024
> +#define OWL_REG_SD_DAT  0x0028
> +#define OWL_REG_SD_BLK_SIZE 0x002c
> +#define OWL_REG_SD_BLK_NUM  0x0030
> +#define OWL_REG_SD_BUF_SIZE 0x0034
> +
> +/* SD_EN Bits */
> +#define OWL_SD_EN_RANE  BIT(31)
> +#define OWL_SD_EN_RESE  BIT(10)
> +#define OWL_SD_ENABLE   BIT(7)
> +#define OWL_SD_EN_BSEL  BIT(6)
> +#define OWL_SD_EN_DATAWID(x)(((x) & 0x3) << 0)
> +
> +/* SD_CTL Bits */
> +#define OWL_SD_CTL_TOUTEN   BIT(31)
> +#define OWL_SD_CTL_DELAY_MSKGENMASK(23, 16)
> +#define OWL_SD_CTL_RDELAY(x)(((x) & 0xf) << 20)
> +#define OWL_SD_CTL_WDELAY(x)(((x) & 0xf) << 16)
> +#define OWL_SD_CTL_TS   BIT(7)
> +#define OWL_SD_CTL_LBE  BIT(6)
> +#define OWL_SD_CTL_TM(x)(((x) & 0xf) << 0)
> +
> +#define OWL_SD_DELAY_LOW_CLK0x0f
> +#define OWL_SD_DELAY_MID_CLK0x0a
> +#define OWL_SD_RDELAY_HIGH   0x08
> +#define OWL_SD_WDELAY_HIGH   0x09
> +
> +/* SD_STATE Bits */
> +#define OWL_SD_STATE_CLNR   BIT(4)
> +#define OWL_SD_STATE_CRC7ER BIT(0)
> +#define OWL_SD_STATE_DAT0S  BIT(7)
> +
> +#define OWL_MMC_OCR (MMC_VDD_32_33 | MMC_VDD_33_34 | \
> +  MMC_VDD_165_195)
> +
> +#define DATA_TRANSFER_TIMEOUT(3 * (100 * 1000))
> +
> +/*
> + * Simple DMA transfer operations defines for MMC/SD card
> + */
> +#define DMA0_CHANNEL_BASE(x) (0xe0230100 + 0x100 * (x))
> +
> +#define DMA_MODE 0x
> +#define DMA_SOURCE   0x0004
> +#define DMA_DESTINATION  0x0008
> +#define DMA_FRAME_LEN0x000C
> +#define DMA_FRAME_CNT 

Re: [PATCH 4/6] ARM: dts: s700: add MMC/SD controller node

[André Przywara]

On 13/12/2020 09:44, Amit Singh Tomar wrote:
> This patch adds node for ethernet controller found on Action Semi OWL
> S700 SoC.
> 
> Since, upstream Linux binding has not been merged for S700 MMC/SD
> controller, Changes are put in u-boot specific dtsi file.

So what's the mainline state of this? If it's going to be merged into
5.11-rc1, we can surely wait for the two weeks.

Cheers,
Andre


> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  arch/arm/dts/s700-u-boot.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
> index 1b27682..3c3396b 100644
> --- a/arch/arm/dts/s700-u-boot.dtsi
> +++ b/arch/arm/dts/s700-u-boot.dtsi
> @@ -19,6 +19,16 @@
>   status = "okay";
>  };
>  
> + mmc0: mmc@e021 {
> + compatible = "actions,s700-mmc", "actions,owl-mmc";
> + reg = <0x0 0xe021 0x0 0x4000>;
> + interrupts = ;
> + clocks = < CLK_SD0>;
> + dmas = < 2>;
> + dma-names = "mmc";
> + bus-width = <4>;
> + status = "okay";
> + };
>   };
>  };
>  
> 

Re: [PATCH 2/6] clk: actions: Add SD/MMC clocks

[André Przywara]

On 13/12/2020 09:44, Amit Singh Tomar wrote:

Hi,

> This commit adds SD/MMC clocks, and provides .set/get_rate callbacks
> for SD/MMC device present on Actions OWL S700 SoCs.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  drivers/clk/owl/clk_owl.c | 66 
> +++
>  drivers/clk/owl/clk_owl.h |  2 ++
>  2 files changed, 68 insertions(+)
> 
> diff --git a/drivers/clk/owl/clk_owl.c b/drivers/clk/owl/clk_owl.c
> index c9bc5c2..49a492c 100644
> --- a/drivers/clk/owl/clk_owl.c
> +++ b/drivers/clk/owl/clk_owl.c
> @@ -92,6 +92,9 @@ int owl_clk_enable(struct clk *clk)
>   setbits_le32(priv->base + CMU_DEVCLKEN1, CMU_DEVCLKEN1_ETH);
>   setbits_le32(priv->base + CMU_ETHERNETPLL, 5);
>   break;
> + case CLK_SD0:
> + setbits_le32(priv->base + CMU_DEVCLKEN0, CMU_DEVCLKEN0_SD0);
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -121,6 +124,9 @@ int owl_clk_disable(struct clk *clk)
>   case CLK_ETHERNET:
>   clrbits_le32(priv->base + CMU_DEVCLKEN1, CMU_DEVCLKEN1_ETH);
>   break;
> + case CLK_SD0:
> + clrbits_le32(priv->base + CMU_DEVCLKEN0, CMU_DEVCLKEN0_SD0);
> + break;
>   default:
>   return -EINVAL;
>   }
> @@ -128,12 +134,69 @@ int owl_clk_disable(struct clk *clk)
>   return 0;
>  }
>  
> +static ulong owl_get_sd_clk_rate(struct owl_clk_priv *priv, int sd_index)
> +{
> + ulong parent_rate;
> + uint div = 1;
> +
> + /* Clock output of DEV_PLL
> +  * Range: 48M ~ 756M
> +  * Frequency= DEVPLLCLK * 6
> +  */
> + parent_rate = readl(priv->base + CMU_DEVPLL) & 0x7f;

According to the datasheet the clock source could also be NAND_PLL,
depending on bit 9.
Both PLLs use the same rate calculation, so it's just matter of the PLL
address offset to use for covering both.

> + parent_rate *= 600;
> +
> + div += readl(priv->base + (CMU_SD0CLK + sd_index*0x4)) & 0x1f;
> +
> + return (parent_rate / div);
> +}
> +
> +static ulong owl_set_sd_clk_rate(struct owl_clk_priv *priv, ulong rate,
> +  int sd_index)
> +{
> + ulong parent_rate;
> + uint div = 1, val;

Unneeded initialisation, you overwrite this below.

> +
> + /* Clock output of DEV_PLL
> +  * Range: 48M ~ 756M
> +  * Frequency= DEVPLLCLK * 6
> +  */
> + parent_rate = readl(priv->base + CMU_DEVPLL) & 0x7f;
> + parent_rate *= 600;
> +
> + rate *= 2;

Where does this come from?

> + div = (parent_rate / rate) - 1;

Please check rate being not zero before you dividing by it. And I would
keep the real divider value for now, so drop the -1 here.

> +
> + if (div >= 128)
> + div |= 0x100;

This does not seem right. You would need to divide the value by 128,
once you decided to use the "divide-by-128" bit (which is bit 8).
What about moving this below, after you know the register value?
Then you can divide by 128 and set bit 8.

> +
> + val = readl(priv->base + (CMU_SD0CLK + sd_index*0x4));
> + /* Bits 4..0 is used to program div value */
> + val &= ~0x1f;
> + val |= div;

Please mask div before applying.

> + /* As per Manuals Bits 31..10 are reserved but Bits 11 and
> +  * 10 needed to be set for proper operation
> +  */
> + val |= 0xc00;

Where does this come from? I don't see the Linux driver doing that?

> + /* Bit 9 and 8 must be cleared */

Bit 9 is the parent clock selection, which you hard code to DEV_CLK.
Bit 8 is the divide-by-128 bit.
Please split those two up and explain it in a comment, maybe.

Cheers,
Andre

> + if (div < 128)
> + val &= ~0x300;
> + else
> + val &= ~0x200;
> + writel(val, priv->base + (CMU_SD0CLK + sd_index*0x4));
> +
> + return owl_get_sd_clk_rate(priv, 0);
> +}
> +
>  static ulong owl_clk_get_rate(struct clk *clk)
>  {
>   struct owl_clk_priv *priv = dev_get_priv(clk->dev);
>   ulong rate;
>  
>   switch (clk->id) {
> + case CLK_SD0:
> + rate = owl_get_sd_clk_rate(priv, 0);
> + break;
>   default:
>   return -ENOENT;
>   }
> @@ -147,6 +210,9 @@ static ulong owl_clk_set_rate(struct clk *clk, ulong rate)
>   ulong new_rate;
>  
>   switch (clk->id) {
> + case CLK_SD0:
> + new_rate = owl_set_sd_clk_rate(priv, rate, 0);
> + break;
>   default:
>   return -ENOENT;
>   }
> diff --git a/drivers/clk/owl/clk_owl.h b/drivers/clk/owl/clk_owl.h
> index a01f81a..ee5eba4 100644
> --- a/drivers/clk/owl/clk_owl.h
> +++ b/drivers/clk/owl/clk_owl.h
> @@ -62,4 +62,6 @@ struct owl_clk_priv {
>  #define CMU_DEVCLKEN1_UART5  BIT(21)
>  #define CMU_DEVCLKEN1_UART3  BIT(11)
>  
> +#define CMU_DEVCLKEN0_SD0BIT(22)
> +
>  #endif
> 

Re: [PATCH 1/6] clk: actions: Introduce dummy get/set_rate callbacks

[André Przywara]

On 13/12/2020 09:43, Amit Singh Tomar wrote:
> This commit introduces get/set_rate callbacks, these are dummy at
> the moment, and can be used to get/set clock for various devices
> based on the clk id.
> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  drivers/clk/owl/clk_owl.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/clk/owl/clk_owl.c b/drivers/clk/owl/clk_owl.c
> index 1999c87..c9bc5c2 100644
> --- a/drivers/clk/owl/clk_owl.c
> +++ b/drivers/clk/owl/clk_owl.c
> @@ -128,6 +128,32 @@ int owl_clk_disable(struct clk *clk)
>   return 0;
>  }
>  
> +static ulong owl_clk_get_rate(struct clk *clk)
> +{
> + struct owl_clk_priv *priv = dev_get_priv(clk->dev);

This is a bit premature and leads to compilation warnings.

> + ulong rate;
> +
> + switch (clk->id) {
> + default:
> + return -ENOENT;
> + }
> +
> + return rate;
> +}
> +
> +static ulong owl_clk_set_rate(struct clk *clk, ulong rate)
> +{
> + struct owl_clk_priv *priv = dev_get_priv(clk->dev);

Same here.

Cheers,
Andre

> + ulong new_rate;
> +
> + switch (clk->id) {
> + default:
> + return -ENOENT;
> + }
> +
> + return new_rate;
> +}
> +
>  static int owl_clk_probe(struct udevice *dev)
>  {
>   struct owl_clk_priv *priv = dev_get_priv(dev);
> @@ -145,6 +171,8 @@ static int owl_clk_probe(struct udevice *dev)
>  static const struct clk_ops owl_clk_ops = {
>   .enable = owl_clk_enable,
>   .disable = owl_clk_disable,
> + .get_rate = owl_clk_get_rate,
> + .set_rate = owl_clk_set_rate,
>  };
>  
>  static const struct udevice_id owl_clk_ids[] = {
> 

Re: [PATCH v1] sunxi: board: Move USB ethernet initialization to board_late_init()

[André Przywara]

On 08/12/2020 15:45, Andy Shevchenko wrote:
> For the sake of consistency (*) and order of initialization, i.e.
> after we have got the ethernet address, interrupt and timer initialized,
> try to initialize USB ethernet gadget.
> 
> *) for example, zynqmp uses same order.

Looks alright, but we need some testing, to check for possible side
effects. (It's those seemingly innocent changes that tend to break things).
Will get back to you later.

Cheers,
Andre

> 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/arm/Kconfig| 1 +
>  board/sunxi/board.c | 5 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5903c093705a..3d9be8a7507e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1045,6 +1045,7 @@ config ARCH_SUNXI
>   select SPL_USE_TINY_PRINTF
>   select USE_PREBOOT
>   select SYS_RELOC_GD_ENV_ADDR
> + imply BOARD_LATE_INIT
>   imply CMD_DM
>   imply CMD_GPT
>   imply CMD_UBI if MTD_RAW_NAND
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 708a27ed78e9..77e464718846 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -890,6 +890,11 @@ int misc_init_r(void)
>  
>   setup_environment(gd->fdt_blob);
>  
> + return 0;
> +}
> +
> +int board_late_init(void)
> +{
>  #ifdef CONFIG_USB_ETHER
>   usb_ether_init();
>  #endif
> 

Re: [RFC] sunxi phy-mode rgmii-id

[André Przywara]

On 29/11/2020 23:07, Heinrich Schuchardt wrote:

Hi,

> since Linux patch
> bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
> i.e. since v5.8.15 or v5.9 many if not all Sunxi A64, H6, H5 boards
> require phy-mode = "rgmii-id" to provide network in Linux
> 
> The U-Boot device-tree is the fallback in the UEFI sub-system if no
> other device-tree is provided. So it would make sense to adjust the
> U-Boot device-trees too.
> 
> The Linux patch has specifically changed the values corresponding to our
> U-Boot defines:
> 
> #define MIIM_RTL8211E_CONFREG_TXD   0x0002
> #define MIIM_RTL8211E_CONFREG_RXD   0x0004
> 
> At least my experience with the NanoPi Neo 2 and the Pine64 A64 LTS
> indicates that setting phy-mode = "rgmii-id" in the device-tree does not
> stop the operation of the network even if the driver is not adjusted.

That is not entirely true, it depends on a patch to not reject other
phy-modes in the Linux driver (f1239d8aa84d).
This entered with v5.5, I believe, and was backported to stable kernels
since, but is not universally available in older kernels. Especially
installers comes to mind ...

But first we need at least the equivalent patch for U-Boot, as I posted
here:
https://lists.denx.de/pipermail/u-boot/2020-November/432823.html

> To avoid breaking boards like Linux did we should change the
> device-trees before or in sync with drivers/net/phy/realtek.c.

Eventually: yes, but at the cost of breaking older kernels. This is
really an unfortunate situation, and actually should not have happened:
normally we at least guarantee operation of newer kernels with older DTs.

Cheers,
Andre

Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support

[André Przywara]

On 19/11/2020 19:59, Priit Laes wrote:
> On Thu, Nov 19, 2020 at 10:54:42AM +, Andre Przywara wrote:
>> So far we did not support the BootROM based FEL USB debug mode on the
>> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
>> SPL runs in AArch64.
>> Returning back to AArch32 was not working as expected, since the RMR
>> reset into 32-bit mode always starts execution in the BootROM, but not
>> in the FEL routine.
>>
>> After some debug and research and with help via IRC, the CPU hotplug
>> mechanism emerged as a solution: If a certain R_CPUCFG register contains
>> some magic, the BootROM will immediately branch to an address stored in
>> some other register. This works well for our purposes.
>>
>> Enable the FEL feature by providing early AArch32 code to first save the
>> FEL state, *before* initially entering AArch64.
>> If we eventually determine that we should return to FEL, we reset back
>> into AArch32, and use the CPU hotplug mechanism to run some small
>> AArch32 code snippet that restores the initially saved FEL state.
>>
>> That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
>> tool, with it returning into FEL mode, so that other payloads can be
>> transferred via FEL as well.
>>
>> Tested on A64, H5 and H6.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm/cpu/armv8/Makefile |  2 +
>>  arch/arm/cpu/armv8/fel_utils.S  | 78 +
>>  arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
>>  include/configs/sunxi-common.h  |  2 -
>>  4 files changed, 94 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm/cpu/armv8/fel_utils.S
> 
> Don't you want to also update board/sunxi/README.sunxi64 ?

Yes, but I am in the process of rewriting this anyway, since some parts
apply to 32-bit SoCs as well (SD card, SPI flash), and there is
currently no documentation about them. So bear with me, I will post a
documentation update ASAP, just didn't want to hold back this patch.

Thanks!
Andre.

>>
>> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
>> index 93d26f98568..f7b4a5ee46c 100644
>> --- a/arch/arm/cpu/armv8/Makefile
>> +++ b/arch/arm/cpu/armv8/Makefile
>> @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC)+= smccc-call.o
>>  
>>  ifndef CONFIG_SPL_BUILD
>>  obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
>> +else
>> +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
>>  endif
>>  obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o 
>> sec_firmware_asm.o
>>  
>> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
>> new file mode 100644
>> index 000..334fdef7fa0
>> --- /dev/null
>> +++ b/arch/arm/cpu/armv8/fel_utils.S
>> @@ -0,0 +1,78 @@
>> +/*
>> + * Utility functions for FEL mode, when running SPL in AArch64.
>> + *
>> + * Copyright (c) 2017 Arm Ltd.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * We don't overwrite save_boot_params() here, to save the FEL state upon
>> + * entry, since this would run *after* the RMR reset, which clobbers that
>> + * state.
>> + * Instead we store the state _very_ early in the boot0 hook, *before*
>> + * resetting to AArch64.
>> + */
>> +
>> +/*
>> + * The FEL routines in BROM run in AArch32.
>> + * Reset back into 32-bit mode here and restore the saved FEL state
>> + * afterwards.
>> + * Resetting back into AArch32/EL3 using the RMR always enters the BROM,
>> + * but we can use the CPU hotplug mechanism to branch back to our code
>> + * immediately.
>> + */
>> +ENTRY(return_to_fel)
>> +/*
>> + * the RMR reset will clear all registers, so save the arguments
>> + * (LR and SP) in the fel_stash structure, which we read anyways later
>> + */
>> +adr x2, fel_stash
>> +str w0, [x2]
>> +str w1, [x2, #4]
>> +
>> +adr x1, fel_stash_addr  // to find the fel_stash address in AA32
>> +str w2, [x1]
>> +
>> +ldr x0, =0xfa50392f // CPU hotplug magic
>> +#ifndef CONFIG_MACH_SUN50I_H6
>> +ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
>> +str w0, [x2, #0x8]
>> +#else
>> +ldr x2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
>> +str w0, [x2], #0x4
>> +#endif
>> +adr x0, back_in_32
>> +str w0, [x2]
>> +
>> +dsb sy
>> +isb sy
>> +mov x0, #2  // RMR reset into AArch32
>> +dsb sy
>> +msr RMR_EL3, x0
>> +isb sy
>> +1:  wfi
>> +b   1b
>> +
>> +/* AArch32 code to restore the state from fel_stash and return back to FEL. 
>> */
>> +back_in_32:
>> +.word   0xe59f0028  // ldr  r0, [pc, #40]   ; load fel_stash address
>> +.word   0xe5901008  // ldr  r1, [r0, #8]
>> +.word   0xe129f001  // msr  CPSR_fc, r1
>> +.word   0xf57ff06f  // isb
>> +.word   0xe590d000  // ldr  sp, 

Re: [PATCH v3] sunxi: add PineCube board

[André Przywara]

On 18/11/2020 10:27, Icenowy Zheng wrote:

> PineCube is an IP camera development kit released by Pine64.
> 
> It comes with the following compoents:
> 
> - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC,
> a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps
> Ethernet port and FPC connectors for camera and daughter board.
> - An OV5640-based camera module which is connected to the parallel CSI
> bus of the mainboard.
> - A daughterboard with several buttons, a SD slot, some IR LEDs, a
> microphone and a speaker connector.
> 
> As the device tree is synchronized in a previous commit, just add it to
> Makefile, create a new MAINTAINER item and provide a defconfig.

Thanks for the quick fix. I could now compile an image.

> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> Changes since v2:
> - Add Makefile reference to DT.
> Changes since v1:
> - Dropped LDO3 quirk.
> 
>  arch/arm/dts/Makefile  |  1 +
>  board/sunxi/MAINTAINERS|  5 +
>  configs/pinecube_defconfig | 15 +++
>  3 files changed, 21 insertions(+)
>  create mode 100644 configs/pinecube_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7d1a369845..e6993733b0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -587,6 +587,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
>   sun8i-r40-bananapi-m2-ultra.dtb \
>   sun8i-v40-bananapi-m2-berry.dtb
>  dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> + sun8i-s3-pinecube.dtb \
>   sun8i-v3s-licheepi-zero.dtb
>  dtb-$(CONFIG_MACH_SUN50I_H5) += \
>   sun50i-h5-bananapi-m2-plus.dtb \
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index d3755ae41a..735801ae1d 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -440,6 +440,11 @@ M:   Vasily Khoruzhick 
>  S:   Maintained
>  F:   configs/pinebook_defconfig
>  
> +PINECUBE BOARD:
> +M:   Icenowy Zheng 
> +S:   Maintained
> +F:   configs/pinecube_defconfig
> +
>  PINE64 BOARDS
>  M:   Andre Przywara 
>  S:   Maintained
> diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig
> new file mode 100644
> index 00..a8c404f6b1
> --- /dev/null
> +++ b/configs/pinecube_defconfig
> @@ -0,0 +1,15 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN8I_V3S=y
> +CONFIG_SUNXI_DRAM_DDR3_1333=y
> +CONFIG_DRAM_CLK=504
> +CONFIG_DRAM_ODT_EN=y
> +CONFIG_I2C0_ENABLE=y
> +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube"
> +CONFIG_SPL_I2C_SUPPORT=y
> +# CONFIG_NETDEVICES is not set
> +CONFIG_AXP209_POWER=y
> +CONFIG_AXP_DCDC2_VOLT=1250
> +CONFIG_AXP_DCDC3_VOLT=3300
> +CONFIG_CONS_INDEX=3
> 

Re: [PATCH v2] sunxi: add PineCube board

[André Przywara]

On 18/11/2020 06:29, Icenowy Zheng wrote:
> PineCube is an IP camera development kit released by Pine64.
> 
> It comes with the following compoents:
> 
> - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC,
> a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps
> Ethernet port and FPC connectors for camera and daughter board.
> - An OV5640-based camera module which is connected to the parallel CSI
> bus of the mainboard.
> - A daughterboard with several buttons, a SD slot, some IR LEDs, a
> microphone and a speaker connector.
> 
> As the device tree is synchronized in a previous commit,

It was, but it is missing the line in the dts Makefile:
...
dts/Makefile:33: recipe for target 'arch/arm/dts/sun8i-s3-pinecube.dtb'
failed
...

Can you please add this and resend?

And out of curiosity: what's with the Ethernet? Looks like a
straight-forward sun8i-emac, doesn't it?

Cheers,
Andre

> just add MAINTAINER item and a defconfig.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Removed LDO3 hack in U-Boot because LDO3 is kept disabled in U-Boot.
> 
>  board/sunxi/MAINTAINERS|  5 +
>  configs/pinecube_defconfig | 15 +++
>  2 files changed, 20 insertions(+)
>  create mode 100644 configs/pinecube_defconfig
> 
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index d3755ae41a..735801ae1d 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -440,6 +440,11 @@ M:   Vasily Khoruzhick 
>  S:   Maintained
>  F:   configs/pinebook_defconfig
>  
> +PINECUBE BOARD:
> +M:   Icenowy Zheng 
> +S:   Maintained
> +F:   configs/pinecube_defconfig
> +
>  PINE64 BOARDS
>  M:   Andre Przywara 
>  S:   Maintained
> diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig
> new file mode 100644
> index 00..a8c404f6b1
> --- /dev/null
> +++ b/configs/pinecube_defconfig
> @@ -0,0 +1,15 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN8I_V3S=y
> +CONFIG_SUNXI_DRAM_DDR3_1333=y
> +CONFIG_DRAM_CLK=504
> +CONFIG_DRAM_ODT_EN=y
> +CONFIG_I2C0_ENABLE=y
> +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube"
> +CONFIG_SPL_I2C_SUPPORT=y
> +# CONFIG_NETDEVICES is not set
> +CONFIG_AXP209_POWER=y
> +CONFIG_AXP_DCDC2_VOLT=1250
> +CONFIG_AXP_DCDC3_VOLT=3300
> +CONFIG_CONS_INDEX=3
> 

Re: Pull request: u-boot-sunxi/master

[André Przywara]

On 17/11/2020 01:56, Samuel Holland wrote:
> On 11/16/20 10:58 AM, Tom Rini wrote:
>> On Mon, Nov 16, 2020 at 04:51:32PM +0000, André Przywara wrote:
>>> On 16/11/2020 16:13, Tom Rini wrote:
>>>> On Mon, Nov 16, 2020 at 04:09:42PM +, André Przywara wrote:
>>>>> On 16/11/2020 15:50, Tom Rini wrote:
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>>> On Mon, Nov 16, 2020 at 12:42:53PM +0530, Jagan Teki wrote:
>>>>>>
>>>>>>> Hi Tom, 
>>>>>>>
>>>>>>> Please pull this PR.
>>>>>>>
>>>>>>> Summary:
>>>>>>> - PinePhone support (Samuel)
>>>>>>> - V3/S3 support (Icenowy)
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jagan.
>>>>>>>
>>>>>>> The following changes since commit 
>>>>>>> de865f7ee1d9b6dff6e265dee44509c8274ea606:
>>>>>>>
>>>>>>>   Merge tag 'efi-2021-01-rc3' of 
>>>>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-11-14 
>>>>>>> 09:47:33 -0500)
>>>>>>>
>>>>>>> are available in the Git repository at:
>>>>>>>
>>>>>>>   https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master
>>>>>>>
>>>>>>> for you to fetch changes up to 27007e5d4a6c4ac1bbd1bc81fb4c19bc45191f35:
>>>>>>>
>>>>>>>   sunxi: dts: sync Allwinner V3s-related DTs from Linux 5.10-rc1 
>>>>>>> (2020-11-16 12:34:09 +0530)
>>>>>>>
>>>>>>
>>>>>> NAK.  A large number of sunxi boards fail to build with:
>>>>>> +board/sunxi/board.c:338:13: error: 'set_spl_dt_name' defined but not 
>>>>>> used [-Werror=unused-function]
>>>>>> +  338 | static void set_spl_dt_name(const char *name)
>>>>>> +  | ^~~
>>>>>> +cc1: all warnings being treated as errors
>>>>>> +make[2]: *** [board/sunxi/board.o] Error 1
>>>>>> +make[1]: *** [board/sunxi] Error 2
>>>>>> +make: *** [sub-make] Error 2
>>>>>
>>>>> Ouch, thanks for that heads up!
>>>>> But this only happens after this very patch, and is fixed by a later
>>>>> patch, right? ("sunxi: board: Set fdtfile to match the DT chosen by SPL"
>>>>> introduces another user of set_spl_dt_name(), outside of any #ifdef's).
>>>>
>>>> No, that's from the PR itself.
>>>
>>> Right, sorry, looked at the wrong function.
>>> I found the culprit and have a fix, but I will run some actual tests on
>>> my boards tonight to make sure it really works.
>>> Jagan or me will send a new PR later then.
>>
>> OK, thanks for the quick follow-up!
> 
> Thank you, Andre, and sorry for the breakage.

No worries, I should have spotted it myself during the review. But it
just points to the fact that board.c is "ifdef hell" at its best, we
should clean that up one day.

And that taught me a lesson to not forget about those poor 32-bit boards ;-)

> For what it's worth, I am happy with the fixups you made.

Thanks for the confirmation!

Cheers,
Andre

Re: Pull request: u-boot-sunxi/master

[André Przywara]

On 16/11/2020 16:13, Tom Rini wrote:
> On Mon, Nov 16, 2020 at 04:09:42PM +0000, André Przywara wrote:
>> On 16/11/2020 15:50, Tom Rini wrote:
>>
>> Hi Tom,
>>
>>> On Mon, Nov 16, 2020 at 12:42:53PM +0530, Jagan Teki wrote:
>>>
>>>> Hi Tom, 
>>>>
>>>> Please pull this PR.
>>>>
>>>> Summary:
>>>> - PinePhone support (Samuel)
>>>> - V3/S3 support (Icenowy)
>>>>
>>>> thanks,
>>>> Jagan.
>>>>
>>>> The following changes since commit 
>>>> de865f7ee1d9b6dff6e265dee44509c8274ea606:
>>>>
>>>>   Merge tag 'efi-2021-01-rc3' of 
>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-11-14 09:47:33 
>>>> -0500)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master
>>>>
>>>> for you to fetch changes up to 27007e5d4a6c4ac1bbd1bc81fb4c19bc45191f35:
>>>>
>>>>   sunxi: dts: sync Allwinner V3s-related DTs from Linux 5.10-rc1 
>>>> (2020-11-16 12:34:09 +0530)
>>>>
>>>
>>> NAK.  A large number of sunxi boards fail to build with:
>>> +board/sunxi/board.c:338:13: error: 'set_spl_dt_name' defined but not used 
>>> [-Werror=unused-function]
>>> +  338 | static void set_spl_dt_name(const char *name)
>>> +  | ^~~
>>> +cc1: all warnings being treated as errors
>>> +make[2]: *** [board/sunxi/board.o] Error 1
>>> +make[1]: *** [board/sunxi] Error 2
>>> +make: *** [sub-make] Error 2
>>
>> Ouch, thanks for that heads up!
>> But this only happens after this very patch, and is fixed by a later
>> patch, right? ("sunxi: board: Set fdtfile to match the DT chosen by SPL"
>> introduces another user of set_spl_dt_name(), outside of any #ifdef's).
> 
> No, that's from the PR itself.

Right, sorry, looked at the wrong function.
I found the culprit and have a fix, but I will run some actual tests on
my boards tonight to make sure it really works.
Jagan or me will send a new PR later then.

Thanks!
Andre.

Re: Pull request: u-boot-sunxi/master

[André Przywara]

On 16/11/2020 15:50, Tom Rini wrote:

Hi Tom,

> On Mon, Nov 16, 2020 at 12:42:53PM +0530, Jagan Teki wrote:
> 
>> Hi Tom, 
>>
>> Please pull this PR.
>>
>> Summary:
>> - PinePhone support (Samuel)
>> - V3/S3 support (Icenowy)
>>
>> thanks,
>> Jagan.
>>
>> The following changes since commit de865f7ee1d9b6dff6e265dee44509c8274ea606:
>>
>>   Merge tag 'efi-2021-01-rc3' of 
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-11-14 09:47:33 
>> -0500)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master
>>
>> for you to fetch changes up to 27007e5d4a6c4ac1bbd1bc81fb4c19bc45191f35:
>>
>>   sunxi: dts: sync Allwinner V3s-related DTs from Linux 5.10-rc1 (2020-11-16 
>> 12:34:09 +0530)
>>
> 
> NAK.  A large number of sunxi boards fail to build with:
> +board/sunxi/board.c:338:13: error: 'set_spl_dt_name' defined but not used 
> [-Werror=unused-function]
> +  338 | static void set_spl_dt_name(const char *name)
> +  | ^~~
> +cc1: all warnings being treated as errors
> +make[2]: *** [board/sunxi/board.o] Error 1
> +make[1]: *** [board/sunxi] Error 2
> +make: *** [sub-make] Error 2

Ouch, thanks for that heads up!
But this only happens after this very patch, and is fixed by a later
patch, right? ("sunxi: board: Set fdtfile to match the DT chosen by SPL"
introduces another user of set_spl_dt_name(), outside of any #ifdef's).

I will try to think about a solution, unless Samuel beats me to it.

Cheers,
Andre

Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support

[André Przywara]

On 10/11/2020 12:38, Tom Rini wrote:

Hi Tom,

> On Sun, Nov 08, 2020 at 03:48:23PM +0000, André Przywara wrote:
>> On 08/11/2020 14:59, Peter Robinson wrote:
>>
>> Hi,
>>
>>> On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara  
>>> wrote:
>>>>
>>>> The eMMC standard describes the concept of boot partitions, consisting
>>>> of two storage areas separate from the main user data partition.
>>>> The Allwinner BootROM supports loading SPL/Boot0 from such a boot
>>>> partition, if that is configured in the eMMC device [1].
>>>>
>>>> To load U-Boot proper along with the SPL from there, currently this
>>>> requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this
>>>> build won't boot from the normal eMMC user partition anymore.
>>>> Also the raw MMC sector offset needs to be adjusted manually, preventing
>>>> a boot from an SD card.
>>>>
>>>> This series introduces automatic detection of eMMC boot partition boot.
>>>> Patch 3/5 automates the raw MMC sector offset decision, allowing such
>>>> a build to also boot from an SD card.
>>>> Unfortunately the BootROM does not mark an eMMC boot partition boot
>>>> differently from the normal eMMC user data partition boot, so patch 4/5
>>>> introduces a function that repeats the BootROM algorithm, so that the SPL
>>>> comes to the same conclusion as the BootROM. This allows to build one
>>>> single image that boots from everywhere: eMMC user data, eMMC boot,
>>>> SD card, SPI flash.
>>>> Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5
>>>> extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible.
>>>>
>>>> Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by
>>>> 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size
>>>> goes up by 444 bytes (AArch64) and 260 bytes (ARMv7).
>>>> Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5
>>>> enables this new mechanism for some boards I could test this on.
>>>>
>>>> Please have a look and test this if you have a board with eMMC.
>>>> I put installation instructions into the linux-sunxi Wiki:
>>>> http://linux-sunxi.org/Bootable_eMMC
>>>
>>> It would probably be good to put that link in the local Allwinner docs
>>> so it's easier for people to find.
>>
>> Yeah, actually as you mention it:
>> There does not seem to be some generic README.sunxi file where this
>> would belong to.
>>
>> Jagan: would it make sense to create one, and describe how to get U-Boot
>> into the devices (SD card, eMMC, SPI flash, FEL)? That could move some
>> parts of README.sunxi64 out of there, since they apply to all Allwinner
>> devices.
>>
>> If people agree that this is the right thing to do, I would be happy to
>> send a patch.
> 
> Well, rST file in doc/boards/ and all of that, but, yes please.

Ah, thanks for the pointer, looks good.
Do we accept symlinks in the tree? There are quite some references to
board/sunxi/README.sunxi64 out there. Or shall I keep a stub instead?

Cheers,
Andre

Re: [PATCH v3] sunxi: a64: Add a defconfig for the PinePhone

[André Przywara]

On 03/11/2020 03:32, Samuel Holland wrote:
> The PinePhone is a smartphone produced by Pine64, with an A64 SoC,
> 2 or 3 GiB LPDDR3 RAM, 16 or 32 GiB eMMC, 720x1440 MIPI-DSI panel,
> and Quectel EG25-G modem.
> 
> There are two main board revisions: 1.1 for early adopters, and 1.2
> for mass production. Since there is code to detect the board revision
> at boot, one config/image can support both boards.
> 
> Acked-by: Maxime Ripard 
> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Thanks,
Andre

> ---
> 
> Changes v2->v3:
>   - All other patches merged
>   - Added entry to MAINTAINERS
> 
> Changes v1->v2:
>   - Regenerated defconfig with `make savedefconfig`
>   - Added Acked-by tag
> 
>  board/sunxi/MAINTAINERS |  5 +
>  configs/pinephone_defconfig | 12 
>  2 files changed, 17 insertions(+)
>  create mode 100644 configs/pinephone_defconfig
> 
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index 1180b86db3..d3755ae41a 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -451,6 +451,11 @@ M:   Icenowy Zheng 
>  S:   Maintained
>  F:   configs/pine_h64_defconfig
>  
> +PINEPHONE BOARD
> +M:   Samuel Holland 
> +S:   Maintained
> +F:   configs/pinephone_defconfig
> +
>  R16 EVB PARROT BOARD
>  M:   Quentin Schulz 
>  S:   Maintained
> diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> new file mode 100644
> index 00..64ecef59c9
> --- /dev/null
> +++ b/configs/pinephone_defconfig
> @@ -0,0 +1,12 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL=y
> +CONFIG_MACH_SUN50I=y
> +CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> +CONFIG_DRAM_CLK=552
> +CONFIG_DRAM_ZQ=3881949
> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> +CONFIG_PINEPHONE_DT_SELECTION=y
> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2"
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2"
> 

Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support

[André Przywara]

On 08/11/2020 14:59, Peter Robinson wrote:

Hi,

> On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara  wrote:
>>
>> The eMMC standard describes the concept of boot partitions, consisting
>> of two storage areas separate from the main user data partition.
>> The Allwinner BootROM supports loading SPL/Boot0 from such a boot
>> partition, if that is configured in the eMMC device [1].
>>
>> To load U-Boot proper along with the SPL from there, currently this
>> requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this
>> build won't boot from the normal eMMC user partition anymore.
>> Also the raw MMC sector offset needs to be adjusted manually, preventing
>> a boot from an SD card.
>>
>> This series introduces automatic detection of eMMC boot partition boot.
>> Patch 3/5 automates the raw MMC sector offset decision, allowing such
>> a build to also boot from an SD card.
>> Unfortunately the BootROM does not mark an eMMC boot partition boot
>> differently from the normal eMMC user data partition boot, so patch 4/5
>> introduces a function that repeats the BootROM algorithm, so that the SPL
>> comes to the same conclusion as the BootROM. This allows to build one
>> single image that boots from everywhere: eMMC user data, eMMC boot,
>> SD card, SPI flash.
>> Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5
>> extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible.
>>
>> Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by
>> 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size
>> goes up by 444 bytes (AArch64) and 260 bytes (ARMv7).
>> Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5
>> enables this new mechanism for some boards I could test this on.
>>
>> Please have a look and test this if you have a board with eMMC.
>> I put installation instructions into the linux-sunxi Wiki:
>> http://linux-sunxi.org/Bootable_eMMC
> 
> It would probably be good to put that link in the local Allwinner docs
> so it's easier for people to find.

Yeah, actually as you mention it:
There does not seem to be some generic README.sunxi file where this
would belong to.

Jagan: would it make sense to create one, and describe how to get U-Boot
into the devices (SD card, eMMC, SPI flash, FEL)? That could move some
parts of README.sunxi64 out of there, since they apply to all Allwinner
devices.

If people agree that this is the right thing to do, I would be happy to
send a patch.

Cheers,
Andre

>>
>> [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details
>>
>> Andre Przywara (5):
>>   sunxi: Fix is_boot0_magic macro
>>   spl: mmc: extend spl_mmc_boot_mode() to take mmc argument
>>   sunxi: Simplify eMMC boot partition booting
>>   sunxi: eMMC: Add automatic boot detection
>>   sunxi: defconfig: enable eMMC boot partition support
>>
>>  arch/arm/include/asm/arch-sunxi/spl.h  |  2 +-
>>  arch/arm/mach-imx/spl.c|  2 +-
>>  arch/arm/mach-k3/am6_init.c|  2 +-
>>  arch/arm/mach-k3/j721e_init.c  |  2 +-
>>  arch/arm/mach-omap2/boot-common.c  |  2 +-
>>  arch/arm/mach-rockchip/spl.c   |  2 +-
>>  arch/arm/mach-socfpga/spl_a10.c|  2 +-
>>  arch/arm/mach-socfpga/spl_agilex.c |  2 +-
>>  arch/arm/mach-socfpga/spl_gen5.c   |  2 +-
>>  arch/arm/mach-socfpga/spl_s10.c|  2 +-
>>  arch/arm/mach-stm32mp/spl.c|  2 +-
>>  arch/arm/mach-sunxi/board.c| 94 +-
>>  arch/arm/mach-uniphier/mmc-boot-mode.c |  5 +-
>>  common/spl/spl_mmc.c   |  4 +-
>>  configs/bananapi_m64_defconfig |  1 +
>>  configs/emlid_neutis_n5_devboard_defconfig |  1 +
>>  configs/pine64-lts_defconfig   |  1 +
>>  configs/pine_h64_defconfig |  1 +
>>  include/spl.h  |  3 +-
>>  19 files changed, 113 insertions(+), 19 deletions(-)
>>
>> --
>> 2.17.5
>>

Re: [PATCH v3 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

[André Przywara]

On 08/10/2020 14:02, Heinrich Schuchardt wrote:

Hi,

> On 25.08.20 18:57, Simon Glass wrote:
>> On Mon, 24 Aug 2020 at 22:15, Heinrich Schuchardt  wrote:
>>>
>>> On 7/25/20 8:18 PM, Heinrich Schuchardt wrote:
 The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
 additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
 relocation.

 CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
 verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.

 CONFIG_LOG=Y is another setting requiring additional early malloc
 area, cf. log_init().

 When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
 we see as output in main U-Boot

 alloc_simple() alloc space exhausted

 With this patch the default values of SYS_MALLOC_F_LEN and
 SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.

 Signed-off-by: Heinrich Schuchardt 
 Reviewed-by: Jagan Teki 
>>>
>>> With current pine64-lts_defconfig we get a warning:
>>>
>>> "alloc space exhausted"
>>>
>>> So, please, merge the patch.
>>
>> Reviewed-by: Simon Glass 
>>
>>>
>>> Best regards
>>>
>>> Heinrich
> 
> Hello Jagan, hello Maxime,
> 
> it is merge window but I could not find this patch in
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi

So apparently since commit 4ab3817ff16a ("clk: fixed-rate: Enable
DM_FLAG_PRE_RELOC flag") even the pine64-lts_defconfig is now broken,
because more malloc space is needed for U-Boot proper before relocation.
This patches fixes is.

So can someone PLEASE merge this patch?

To answer this one lingering question: Apparently the malloc memory for
SPL is taken from DRAM (similar to BSS), so we have plenty. The U-Boot
proper early malloc is taken from SRAM A1 (why?), but we don't need it
for anything else any more, so have enough of it. So the 8KB are safe in
both worlds.

Thanks!
Andre

Re: [PATCH] sunxi: make V3s DRAM initialization more proper

[André Przywara]

On 16/10/2020 10:33, Icenowy Zheng wrote:

Hi,

> Previously, because we have no source code about the DRAM initialization
> of V3s and missing some configurations (delays and MBUS QoS info), our
> V3s DRAM initialization sequence is hacked from the H3 one.
> 
> As the SDK shipped with PineCube contains source code for V3s libdram,
> we can retrieve these information from it and tweak some other magic
> bits.

Nice! Thanks for taking care.

> Signed-off-by: Icenowy Zheng 

I couldn't be asked to check the specific bits in the new V3s libdram,
nor do I have any hardware to test this, but I checked the integration
into the driver, and compile tested for the LicheePi and H3 boards.
The code size for H3 stayed the same, for the LicheePi it actually
decreased.
So from this perspective:

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  arch/arm/include/asm/arch-sunxi/cpu.h |  1 +
>  arch/arm/mach-sunxi/dram_sunxi_dw.c   | 91 +--
>  2 files changed, 87 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
> b/arch/arm/include/asm/arch-sunxi/cpu.h
> index 4c399b0a15..8b57d24e2f 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> @@ -16,6 +16,7 @@
>  
>  #define SOCID_A640x1689
>  #define SOCID_H3 0x1680
> +#define SOCID_V3S0x1681
>  #define SOCID_H5 0x1718
>  #define SOCID_R400x1701
>  
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index a462538521..d0600011ff 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -63,6 +63,8 @@ enum {
>   MBUS_PORT_CSI   = 5,
>   MBUS_PORT_NAND  = 6,
>   MBUS_PORT_SS= 7,
> + MBUS_PORT_DE_V3S= 8,
> + MBUS_PORT_DE_CFD_V3S= 9,
>   MBUS_PORT_TS= 8,
>   MBUS_PORT_DI= 9,
>   MBUS_PORT_DE= 10,
> @@ -134,6 +136,29 @@ static void mctl_set_master_priority_h3(void)
>   MBUS_CONF(DE_CFD,  true,HIGH, 0, 1024,  288,   64);
>  }
>  
> +static void mctl_set_master_priority_v3s(void)
> +{
> + struct sunxi_mctl_com_reg * const mctl_com =
> + (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> +
> + /* enable bandwidth limit windows and set windows size 1us */
> + writel((1 << 16) | (400 << 0), _com->bwcr);
> +
> + /* set cpu high priority */
> + writel(0x0001, _com->mapr);
> +
> + MBUS_CONF(   CPU,  true, HIGHEST, 0,  160,  100,   80);
> + MBUS_CONF(   GPU,  true,HIGH, 0, 1792, 1536,0);
> + MBUS_CONF(UNUSED,  true, HIGHEST, 0,  256,  128,   80);
> + MBUS_CONF(   DMA,  true,HIGH, 0,  256,  100,0);
> + MBUS_CONF(VE,  true,HIGH, 0, 2048, 1600,0);
> + MBUS_CONF(   CSI,  true, HIGHEST, 0,  384,  256,0);
> + MBUS_CONF(  NAND,  true,HIGH, 0,  100,   50,0);
> + MBUS_CONF(SS,  true,HIGH, 0,  384,  256,0);
> + MBUS_CONF(DE_V3S, false,HIGH, 0, 8192, 4096,0);
> + MBUS_CONF(DE_CFD_V3S,  true,HIGH, 0,  640,  256,0);
> +}
> +
>  static void mctl_set_master_priority_a64(void)
>  {
>   struct sunxi_mctl_com_reg * const mctl_com =
> @@ -231,6 +256,9 @@ static void mctl_set_master_priority(uint16_t socid)
>   case SOCID_H3:
>   mctl_set_master_priority_h3();
>   return;
> + case SOCID_V3S:
> + mctl_set_master_priority_v3s();
> + return;
>   case SOCID_A64:
>   mctl_set_master_priority_a64();
>   return;
> @@ -334,6 +362,28 @@ static void mctl_h3_zq_calibration_quirk(struct 
> dram_para *para)
>   }
>  }
>  
> +static void mctl_v3s_zq_calibration_quirk(struct dram_para *para)
> +{
> + struct sunxi_mctl_ctl_reg * const mctl_ctl =
> + (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> +
> + u32 reg_val;
> +
> + clrsetbits_le32(_ctl->zqcr, 0xff,
> + CONFIG_DRAM_ZQ & 0xff);
> + mctl_phy_init(PIR_ZCAL);
> +
> + reg_val = readl(_ctl->zqdr[0]);
> + reg_val &= (0x1f << 16) | (0x1f << 0);
> + reg_val |= reg_val << 8;
> + writel(reg_val, _ctl->zqdr[0]);
> +
> + reg_val = readl(_ctl->zqdr[1]);
> + reg_val &= (0x1f << 16) | (0x1f << 0);
> + reg_val |= reg_val << 8;
> + writel(reg_val, _ctl->zqdr[1]);
> +}
> +
>  static void mctl_set_cr(uint16_t socid, struct dram_para *para)
>  {
>   struct sunxi_mctl_com_reg * const mctl_com =
> @@ -391,7 +441,7 @@ static void mctl_sys_init(uint16_t socid, struct 
> dram_para *para)
>   CCM_DRAMCLK_CFG_DIV(1) |
>   CCM_DRAMCLK_CFG_SRC_PLL11 |
>   CCM_DRAMCLK_CFG_UPD);
> - } else if (socid == SOCID_H3 || socid == SOCID_H5) {
> + } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid == 
> 

Re: [PATCH] serial: pl01x: Add error value checking

[André Przywara]

On 14/10/2020 09:42, Michal Simek wrote:

Hi,

> There also a need to check return values to make sure that clocks were
> enabled and setup properly.

is that just clean-up or is there a particular problem that's fixed?

I am asking because I am not sure how useful debug output in a console
driver is.
Also in some cases the UART is actually already configured, so failure
to get the clock (due to a sloppy/too complicated DTB) is not really
fatal at the moment.

I am not against this patch, just wanted to make sure we don't break
anything.

Cheers,
Andre


> 
> Signed-off-by: Michal Simek 
> ---
> 
>  drivers/serial/serial_pl01x.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
> index 2772c25f1d2d..8672095ea4de 100644
> --- a/drivers/serial/serial_pl01x.c
> +++ b/drivers/serial/serial_pl01x.c
> @@ -362,8 +362,18 @@ int pl01x_serial_ofdata_to_platdata(struct udevice *dev)
>   plat->clock = dev_read_u32_default(dev, "clock", CONFIG_PL011_CLOCK);
>   ret = clk_get_by_index(dev, 0, );
>   if (!ret) {
> - clk_enable();
> + ret = clk_enable();
> + if (ret && ret != -ENOSYS) {
> + dev_err(dev, "failed to enable clock\n");
> + return ret;
> + }
> +
>   plat->clock = clk_get_rate();
> + if (IS_ERR_VALUE(plat->clock)) {
> + dev_err(dev, "failed to get rate\n");
> + return plat->clock;
> + }
> + debug("%s: CLK %d\n", __func__, plat->clock);
>   }
>   plat->type = dev_get_driver_data(dev);
>   plat->skip_init = dev_read_bool(dev, "skip-init");
> 

Re: [PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties

[André Przywara]

On 08/10/2020 14:10, Heinrich Schuchardt wrote:

Hi,

> On 14.06.20 17:48, Heinrich Schuchardt wrote:
>> On 6/1/20 6:20 PM, Heinrich Schuchardt wrote:
>>> On 6/1/20 4:43 PM, André Przywara wrote:
>>>> On 01/06/2020 14:56, Heinrich Schuchardt wrote:
>>>>> Provide accurate values of the manufacturer and the product name.
>>>>>
>>>>> PINE Microsystems Inc. is referred to on
>>>>> https://www.pine64.org/contact/.
>>>>
>>>> While this patch looks alright, I wonder if we can just use the "model"
>>>> property in the DT's root node, at least for the product name? This
>>>> would not only avoid every defconfig to be touched, but would also cover
>>>> all other platforms (at least ARM based ones, probably PPC and MIPS as
>>>> well).
>>>
>>> The relevant code is in lib/smbios.c. For boards that follow the driver
>>> model you could read the model node here. But that would unnecessarily
>>> increase the code size of the resulting binary. I doubt this would find
>>> Tom's sympathy. So you would have to generate the value at compile time.
>>> I have no clue how to do that.
>>>
>>> The model property for the PINE A64 LTS is "Pine64 LTS" while the board
>>> is called "PINE A64-LTS" by the manufacturer
>>> (https://www.pine64.org/devices/single-board-computers/pine-a64-lts/).
>>> So this approach does not lead to the correct result.
>>>
>>>>
>>>> The manufacturer is less straight-forward to handle generically, but the
>>>> string before the comma in the DT root's compatible property should give
>>>> a hint. The Linux kernel contains a machine readable list of those
>>>> prefixes: Documentation/devicetree/bindings/vendor-prefixes.yaml
>>>> So we could pick the vendor at compile time based on that.
>>>> Of course any config could still overwrite this.
>>>
>>> SMBIOS_MANUFACTURER defaults to SYS_VENDOR which is defined as "sunxi".
>>>
>>> The Linux vendor-prefix exists for ARM64 and is missing for the ARM
>>> architecture. So this cannot be a general solution.
>>>
>>> For the Pine64 A64-LTS the vendor-prefix is "allwinner". Neither "sunxi"
>>> nor "Allwinner" is the manufacturer of the PINE A64-LTS board.
>>>
>>> You have to set SMBIOS_MANUFACTURER on the board level.
>>>
>>>>
>>>> Does that make sense?
>>>> If people agree, I could try to make a patch for that.
>>>
>>> Please, reconsider the patch as is.
>>
>> Hello Andr+e
>>
>> any comments?
>>
>> Best regards
>>
>> Heinrich
> 
> 
> Hello Andre,
> 
> did you work on your idea of using the model property? Or can Jagan take
> the patch as is?

No, I didn't have time to tackle this yet.

So yes, please Jagan, take this patch as it.

Cheers,
Andre

>>
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>>>
>>>>> Signed-off-by: Heinrich Schuchardt 
>>>>> ---
>>>>>   configs/pine64-lts_defconfig | 2 ++
>>>>>   1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/configs/pine64-lts_defconfig
>>>>> b/configs/pine64-lts_defconfig
>>>>> index ef108a1a31..a8ff34a376 100644
>>>>> --- a/configs/pine64-lts_defconfig
>>>>> +++ b/configs/pine64-lts_defconfig
>>>>> @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949
>>>>>   CONFIG_MMC0_CD_PIN=""
>>>>>   CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>>>>   CONFIG_SPL_SPI_SUNXI=y
>>>>> +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS"
>>>>>   # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>>>>   CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts"
>>>>>   CONFIG_SUN8I_EMAC=y
>>>>>   CONFIG_USB_EHCI_HCD=y
>>>>>   CONFIG_USB_OHCI_HCD=y
>>>>> +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc."
>>>>> --
>>>>> 2.26.2
>>>>>
>>>>
>>>
>>
> 

Re: [PATCH v2] cfi_flash: Fix devicetree address determination

[André Przywara]

On 08/10/2020 11:15, Heinrich Schuchardt wrote:

Hi,

> On 08.10.20 11:49, Stefan Roese wrote:
>> On 08.10.20 10:39, Heinrich Schuchardt wrote:
>>> On 08.10.20 09:08, Stefan Roese wrote:
 On 24.09.20 01:22, Andre Przywara wrote:
> The cfi-flash driver uses an open-coded version of the generic
> algorithm to decode and translate multiple frames of a "reg" property.
>
> This starts off the wrong foot by using the address-cells and
> size-cells
> properties of *this* very node, and not of the parent. This somewhat
> happened to work back when we were using a wrong default size of 2,
> but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
> correct value if #size-cells property is not present").
>
> Instead of fixing the reinvented wheel, just use the generic function
> that does all of this properly.
>
> This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
> a wrong flash base address:
> DRAM:  1 GiB
> Flash: "Synchronous Abort" handler, esr 0x9644
> elr: 000211dc lr : 000211b0 (reloc)
> elr: 7ff5e1dc lr : 7ff5e1b0
> x0 : 00f0 x1 : 7ff5e1d8
> x2 : 7edfbc48 x3 : 
> x4 :  x5 : 00f0
> x6 : 7edfbc2c x7 : 
> x8 : 7ffd8d70 x9 : 000c
> x10: 0403 x11: 0055
>    
>
> Signed-off-by: Andre Przywara 

 Applied to u-boot-cfi-flash/master

 Thanks,
 Stefan

> ---
> Changes v1 .. v2:
> - Use live tree compatible function
> - Drop unneeded size variable
>
>    drivers/mtd/cfi_flash.c | 24 ++--
>    1 file changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index b7289ba5394..9e3a652f445 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
>    #ifdef CONFIG_CFI_FLASH /* for driver model */
>    static int cfi_flash_probe(struct udevice *dev)
>    {
> -    const fdt32_t *cell;
> -    int addrc, sizec;
> -    int len, idx;
> +    fdt_addr_t addr;
> +    int idx;
>    -    addrc = dev_read_addr_cells(dev);
> -    sizec = dev_read_size_cells(dev);
> -
> -    /* decode regs; there may be multiple reg tuples. */
> -    cell = dev_read_prop(dev, "reg", );
> -    if (!cell)
> -    return -ENOENT;
> -    idx = 0;
> -    len /= sizeof(fdt32_t);
> -    while (idx < len) {
> -    phys_addr_t addr;
> -
> -    addr = dev_translate_address(dev, cell + idx);
> +    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
> +    addr = dev_read_addr_index(dev, idx);
>>>
>>> Why don't you additionally read the size here to populate
>>> flash_info[].size?
>>>
>>> fdt_size_t size;
>>> addr = dev_read_addr_size_index(dev, idx, );
>>
>> It was not done before this either. IIRC, then the size is auto detected
>> by querying the flash chip.
>>
>> Do you see any issue without this? Feel free to send a follow up patch
>> is something needs to get fixed / tuned.
> 
> Yes, there is a function flash_get_size().
> 
> I am not worried about this special patch but about the logic of the
> driver as a whole.
> 
> Why does function flash_get_size() consider CONFIG_SYS_FLASH_BANKS_SIZES
> but not the size information from the DTB? Do we need
> CONFIG_SYS_FLASH_BANKS_SIZES and weak function cfi_flash_bank_size() at all?

That's a good point: given that this symbol is in config_whitelist.txt,
it's probably some legacy from the dawn of time.

Maybe for some hacks, as those lines in cfi_flash.c suggest:

max_size = cfi_flash_bank_size(banknum);
if (max_size && info->size > max_size) {
debug("[truncated from %ldMiB]", info->size >> 20);
info->size = max_size;
}


Maybe someone mounted a bigger flash chip than there was space in the
MMIO frame?

But I totally agree that this is very confusing and should either be
removed entirely (preferred, but would need to be tested on those boards
using it) or extended to cover DTBs as well.

Cheers,
Andre

Re: [PATCH 4/5] qemu: Drop ARCH_SUPPORT_TFABOOT

[André Przywara]

On 29/09/2020 14:23, Tom Rini wrote:

Hi Tom,

> On Thu, Sep 24, 2020 at 01:17:14AM +0100, Andre Przywara wrote:
> 
>> CONFIG_ARCH_SUPPORT_TFABOOT seems to be a guard option to enable various
>> platform specific hacks, when U-Boot is run under TF-A.
>> Now that the QEMU port does not need to differentiate between secure
>> vs. non-secure anymore (this is taken care of by the DTB), there is
>> no need for a build-time option anymore, so remove it.
>>
>> Signed-off-by: Andre Przywara 
> 
> I don't quite like calling the changes under TFABOOT hacks in that

Yeah, hack sounds too harsh, apologies for that. I will reword the
commit message. On a first glance the code guarded by that symbol seemed
to be only very loosely connected to TF-A.

> ARCH_SUPPORT_TFABOOT is used to guard TFABOOT and on other platforms
> that's used to enable/disable various non-hacky build time things.
> Maybe we need to tweak the help text on TFABOOT to be clear that only
> may be required on a given platform?

Well, looking more closely now it looks like on STM32 and FSL this makes
the difference between: Does U-Boot handle the secure side (errata
handling, provide PSCI services) or is this done by other firmware (TF-A).
This seems like a legitimate option(*), but this may indeed be better
explained. I can make a patch for that if this seems useful.

Cheers.
Andre


(*) ... although one could argue that this could decided at runtime, by
looking at the EL U-Boot is entered in. But this is quite a separate
discussion and most probably not worth the effort.

Re: [PATCH 1/5] arm64: PIE: Skip fixups if distance is zero

[André Przywara]

On 24/09/2020 21:22, Stephen Warren wrote:

Hi Stephen,

> On 9/24/20 8:45 AM, André Przywara wrote:
>> On 24/09/2020 01:17, Andre Przywara wrote:
>>> When the actual offset between link and runtime address is zero, there
>>> is no need for patching up U-Boot early when running with
>>> CONFIG_POSITION_INDEPENDENT.
>>
>> That turns out to be not fully true.
>> Some toolchains (all Linaro cross compilers?) don't handle this well,
>> they keep the original locations in the binary uninitialised, and rely
>> on the reldyn fixup table to patch in the actual values.
>> Other compilers (GCC 9.2 vanilla, Ubuntu GCC 7.5.0, Arm website 9.2)
>> fill in the addresses both into the binary and the fixup, so this patch
>> works.
>>
>> It seems to be fixed by enabling CONFIG_STATIC_RELA?
>> I see it's disabled for CONFIG_POSITION_INDEPENDENT, what was the reason
>> behind that?
> 
> I can't remember for sure. I tried re-enabling STATIC_RELA at both the
> upstream commit where POSITION_INDEPENDENT was first implemented and at
> top-of-tree, and ran test/py on Tegra, and it works fine. Perhaps I just
> figured there was no need to perform the static relocations since the
> code would always do it? I figure it's safe to re-enable it, i.e.
> decouple the two config options completely.

Many thanks for the reply and the test!
And yeah, I was hoping that it was just for "because we don't need to".

I will send a patch to always use STATIC_RELA for arm64. As Ard pointed
out, it should actually not be needed anymore (for newer binutils), but
the Linaro toolchains miss this change, and quite some people use them.

Cheers,
Andre

Re: [PATCH 1/5] arm64: PIE: Skip fixups if distance is zero

[André Przywara]

On 24/09/2020 01:17, Andre Przywara wrote:
> When the actual offset between link and runtime address is zero, there
> is no need for patching up U-Boot early when running with
> CONFIG_POSITION_INDEPENDENT.

That turns out to be not fully true.
Some toolchains (all Linaro cross compilers?) don't handle this well,
they keep the original locations in the binary uninitialised, and rely
on the reldyn fixup table to patch in the actual values.
Other compilers (GCC 9.2 vanilla, Ubuntu GCC 7.5.0, Arm website 9.2)
fill in the addresses both into the binary and the fixup, so this patch
works.

It seems to be fixed by enabling CONFIG_STATIC_RELA?
I see it's disabled for CONFIG_POSITION_INDEPENDENT, what was the reason
behind that?

Cheers,
Andre.

> 
> Skip the whole routine when the distance is 0.
> 
> This helps when U-Boot is loaded into ROM, or in otherwise sensitive
> memory locations.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/start.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 002698b501c..02b952bb328 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -66,7 +66,8 @@ save_boot_params_ret:
>  pie_fixup:
>   adr x0, _start  /* x0 <- Runtime value of _start */
>   ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
> - sub x9, x0, x1  /* x9 <- Run-vs-link offset */
> + subsx9, x0, x1  /* x9 <- Run-vs-link offset */
> + beq pie_fixup_done
>   adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>   adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>  pie_fix_loop:
> 

Re: [PATCH 0/5] qemu-arm64: Allow booting via Trusted Firmware

[André Przywara]

On 24/09/2020 09:44, Heinrich Schuchardt wrote:
> On 24.09.20 09:57, Amit Tomar wrote:
>> Hi,
>>
>> Andre Przywara (5):
>>
>>   arm64: PIE: Skip fixups if distance is zero
>>   arm64: PIE: Allow fixed stack pointer
>>   qemu-arm: Remove need to specify flash banks
>>   qemu: Drop ARCH_SUPPORT_TFABOOT
>>   qemu/arm64: Enable POSITION_INDEPENDENT
>>
>>  arch/arm/Kconfig             | 4 ++--
>>  arch/arm/cpu/armv8/start.S   | 3 ++-
>>  configs/qemu_arm64_defconfig | 1 +
>>  include/configs/qemu-arm.h   | 8 +---
>>  4 files changed, 6 insertions(+), 10 deletions(-)
>>
>> --
>> 2.17.5
>>
>>
>> I tried testing this series but don't see any output while loading
>> U-Boot from ROM:
>>
>> # ./qemu-system-aarch64 -M virt -cpu cortex-a57 -nographic -smp 1 -bios
>> u-boot.bin
> 
> TF-A runs at EL3 so you should test with
> -machine virt,secure=true,virtualization=true

This is true, but the point of this series is to work both within TF-A
and without it. So it should work (and does for me!) with Amit's line above.

> The bios parameter has to point to the TF-A bl1.bin binary. see TF-A's
> docs/plat/qemu.rst: BL1 is used as the BootROM, supplied with the -bios
> argument.

Yeah, and it seems to be even more complicated, since you have to glue
fip.bin within a certain offset to bl1.bin, into one file to give to
-bios. I use:
$ cp build/qemu/debug/bl1.bin flash.bin
$ dd if=build/qemu/debug/fip.bin of=flash.bin bs=4k seek=64

... and make sure to give QEMU more than 512MB of RAM, since the default
load address for U-Boot is there. Actually fixing this annoyance was the
main motivation for this series.

Once people agreed that this series is making some sense, I plan to move
the load address in TF-A and improve the documentation in both TF-A and
QEMU on this.

Thanks!
Andre

> 
> U-Boot is BL33.
> 
> Best regards
> 
> Heinrich
> 
>>
>> strangely enough SP is having a value of 0 after execution:
>>
>> (qemu) info registers
>>  PC=1a00 X00=54a0f100303f X01=0007c000
>> X02= X03=401fe000 X04=
>> X05= X06=0030 X07=401fe008
>> X08= X09=1408d51e115f X10=
>> X11= X12= X13=
>> X14= X15= X16=
>> X17= X18= X19=
>> X20= X21= X22=
>> X23= X24= X25=
>> X26= X27= X28=
>> X29=00c8 X30=1408d51e39cb  SP=
>> PSTATE=03c5  EL1h     FPCR= FPSR=
>>
>> Wondering , if I have missed something ?
>>
>> Thanks
>> -Amit
> 

Re: [PATCH 0/5] qemu-arm64: Allow booting via Trusted Firmware

[André Przywara]

On 24/09/2020 08:57, Amit Tomar wrote:
> Hi,
> 
> Andre Przywara (5):
> 
>   arm64: PIE: Skip fixups if distance is zero
>   arm64: PIE: Allow fixed stack pointer
>   qemu-arm: Remove need to specify flash banks
>   qemu: Drop ARCH_SUPPORT_TFABOOT
>   qemu/arm64: Enable POSITION_INDEPENDENT
> 
>  arch/arm/Kconfig             | 4 ++--
>  arch/arm/cpu/armv8/start.S   | 3 ++-
>  configs/qemu_arm64_defconfig | 1 +
>  include/configs/qemu-arm.h   | 8 +---
>  4 files changed, 6 insertions(+), 10 deletions(-)
> 
> -- 
> 2.17.5
> 
> 
> I tried testing this series but don't see any output while loading
> U-Boot from ROM:
> 
> # ./qemu-system-aarch64 -M virt -cpu cortex-a57 -nographic -smp 1 -bios
> u-boot.bin

I can't reproduce this (read: works for me).
I tried with cross-gcc 9.2 & QEMU 5.0.0, and with Ubuntu-arm64 (GCC 7.5
& QEMU 2.11.1).
Did you apply against master, used qemu_arm64_defconfig, cleaned the
build directory? Is your (self-built?) QEMU working? Are you using the
actual generated binary?

I pushed the branch to
https://github.com/Andre-ARM/u-boot/commits/qemu-tfa, please try this.

Cheers,
Andre

> 
> strangely enough SP is having a value of 0 after execution:
> 
> (qemu) info registers
>  PC=1a00 X00=54a0f100303f X01=0007c000
> X02= X03=401fe000 X04=
> X05= X06=0030 X07=401fe008
> X08= X09=1408d51e115f X10=
> X11= X12= X13=
> X14= X15= X16=
> X17= X18= X19=
> X20= X21= X22=
> X23= X24= X25=
> X26= X27= X28=
> X29=00c8 X30=1408d51e39cb  SP=
> PSTATE=03c5  EL1h     FPCR= FPSR=
> 
> Wondering , if I have missed something ?
> 
> Thanks
> -Amit

Re: [PATCH] cfi_flash: Fix devicetree address determination

[André Przywara]

On 23/09/2020 06:26, Stefan Roese wrote:
> Hi Simon,
> 
> On 22.09.20 15:51, Simon Glass wrote:
>> Hi Stefan,
>>
>> On Mon, 21 Sep 2020 at 07:28, Stefan Roese  wrote:
>>>
>>> Hi Andre,
>>>
>>> (added Simon)
>>>
>>> On 18.09.20 19:45, Andre Przywara wrote:
 The cfi-flash driver uses an open-coded version of the generic
 algorithm to decode and translate multiple frames of a "reg" property.

 This starts off the wrong foot by using the address-cells and
 size-cells
 properties of *this* very node, and not of the parent. This somewhat
 happened to work back when we were using a wrong default size of 2,
 but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
 correct value if #size-cells property is not present").

 Instead of fixing the reinvented wheel, just use the generic function
 that does all of this properly.

 This fixes U-Boot on QEMU (outside of EL1), which was crashing due to
 decoding a wrong start address:
 DRAM:  1 GiB
 Flash: "Synchronous Abort" handler, esr 0x9644
 elr: 000211dc lr : 000211b0 (reloc)
 elr: 7ff5e1dc lr : 7ff5e1b0
 x0 : 00f0 x1 : 7ff5e1d8
 x2 : 7edfbc48 x3 : 
 x4 :  x5 : 00f0
 x6 : 7edfbc2c x7 : 
 x8 : 7ffd8d70 x9 : 000c
 x10: 0403 x11: 0055
    

 Signed-off-by: Andre Przywara 
 ---
    drivers/mtd/cfi_flash.c | 25 +++--
    1 file changed, 7 insertions(+), 18 deletions(-)

 diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
 index b7289ba5394..656ff326e17 100644
 --- a/drivers/mtd/cfi_flash.c
 +++ b/drivers/mtd/cfi_flash.c
 @@ -2468,29 +2468,18 @@ unsigned long flash_init(void)
    #ifdef CONFIG_CFI_FLASH /* for driver model */
    static int cfi_flash_probe(struct udevice *dev)
    {
 - const fdt32_t *cell;
 - int addrc, sizec;
 - int len, idx;
 + fdt_addr_t addr;
 + fdt_size_t size;
 + int idx;

 - addrc = dev_read_addr_cells(dev);
 - sizec = dev_read_size_cells(dev);
 -
 - /* decode regs; there may be multiple reg tuples. */
 - cell = dev_read_prop(dev, "reg", );
 - if (!cell)
 - return -ENOENT;
 - idx = 0;
 - len /= sizeof(fdt32_t);
 - while (idx < len) {
 - phys_addr_t addr;
 -
 - addr = dev_translate_address(dev, cell + idx);
 + for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
 + addr = devfdt_get_addr_size_index(dev, idx, );
 + if (addr == FDT_ADDR_T_NONE)
 + break;

    flash_info[cfi_flash_num_flash_banks].dev = dev;
    flash_info[cfi_flash_num_flash_banks].base = addr;
    cfi_flash_num_flash_banks++;
 -
 - idx += addrc + sizec;
    }
    gd->bd->bi_flashstart = flash_info[0].base;


>>>
>>> This fails on my Octeon MIPS64 platform "octeon_ebb7304". I did some
>>> debugging and found that here "of_offset" is a 64 bit value (type long)
>>> which gets truncated in dev_of_offset() to 32 bit (type int).
>>>
>>> This problem only arises when of_live_active() is set. Here, "of_offset"
>>> holds a pointer AFACT and truncating it to 32 bits breaks things.
>>>
>>> I'm wondering why this did not hit me earlier on this 64bit platform.
>>> Simon, do you have a quick idea how to solve this?
>>
>> Well I don't think ofnode should use long for of_offset, since int
>> should be enough.
>>
>> ofnode_to_offset() converts an ofnode to a DT offset but only if it is
>> not using livetree. With livetree there are no offsets so this is not
>> going to work. If you define OF_CHECKS you will see that.
> 
> This does not work right now. I'll send a patch fixing compiling with
> OF_CHECK enabled shortly.
> 
>> Note that an ofnode can either hold a pointer or an offset. There are
>> detailed comments on ofnode_union to explain how it is supposed to
>> work.
> 
> Right. Thanks for all the detailed infos in the header. The main issue
> seems to be, that this CFI patch uses a function from fdtaddr.c
> (devfdt_get_addr_size_index), which unconditionally uses dev_of_offset()
> without checking if livetree is enabled or not. This breaks on my
> 64 bit platform (see below).
> 
>> This patch looks correct to me, but perhaps there is something else
>> going on?
> 
> Making this change below, works for me:
> 
> -    addr = devfdt_get_addr_size_index(dev, idx, );
> +    addr = dev_read_addr_index(dev, idx);

Ouch, sorry for that!

One thing I noticed: Technically this fix is no longer needed, since
Heinrich's patch ae6b33dcc342 ("dm: fix ofnode_read_addr/size_cells()")

Re: [PATCH 5/8] sunxi: board: Save the chosen DT name in the SPL header

[André Przywara]

On 22/09/2020 02:12, Samuel Holland wrote:

Hi,

> On 9/21/20 7:41 PM, André Przywara wrote:
>> On 03/09/2020 06:07, Samuel Holland wrote:
>>> This overwrites the name loaded from the SPL image. It will be different
>>> if there was previously no name provided, or if a more accurate name was
>>> determined by the board variant selection logic. This means that the DT> 
>>> name in the SPL header now always matches the DT appended to U-Boot.
>>
>> That's a nice way of preserving all this fancy DT selection choices for
>> U-Boot proper!
>>
>>> Signed-off-by: Samuel Holland 
>>
>> One hint below, but nevertheless:
>>
>> Reviewed-by: Andre Przywara 
>>
>>> ---
>>>  board/sunxi/board.c | 27 ++-
>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>>> index 3d64ed18664..eaa40a1ea96 100644
>>> --- a/board/sunxi/board.c
>>> +++ b/board/sunxi/board.c
>>> @@ -331,6 +331,21 @@ static const char *get_spl_dt_name(void)
>>> return NULL;
>>>  }
>>>  
>>> +static void set_spl_dt_name(const char *name)
>>> +{
>>> +   struct boot_file_head *spl = get_spl_header(SPL_ENV_HEADER_VERSION);
>>> +
>>> +   if (spl == INVALID_SPL_HEADER)
>>> +   return;
>>> +
>>> +   /* Promote the header version for U-Boot proper, if needed. */
>>> +   if (spl->spl_signature[3] < SPL_DT_HEADER_VERSION)
>>> +   spl->spl_signature[3] = SPL_DT_HEADER_VERSION;
>>> +
>>> +   strcpy((char *)>string_pool, name);
>>
>> Let's hope nobody ever optimises the strcpy() routine, as this might
>> break (when doing unaligned accesses) on device memory, as in this case.
> 
> Why would any part of SRAM A1 be mapped as device memory? 

Because we do so in arch/arm/mach-sunxi/board.c:
static struct mm_region sunxi_mem_map[] = {
{
/* SRAM, MMIO regions */
.virt = 0x0UL,
.phys = 0x0UL,
.size = 0x4000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE
}, {


> If U-Boot maps its own code as device memory,

DRAM is mapped as normal cacheable memory (the line after those above).
So U-Boot's code and its own data are safe.

> and then implements a strcpy that requires aligned
> multi-byte access (i.e. cannot handle arbitrary naturally-aligned char *), 
> then
> this code here isn't the bug.

The problem is that letting the compiler generate code that does access
non-normal memory is broken. Device memory needs to be accessed via MMIO
accessors only, everything else is architecturally wrong.
We are somewhat saved by the fact that SRAM, by its very nature,
implements memory semantics, so it supports the GRE semantics that the
compiler relies on. But unaligned accesses trap on device memory
nevertheless.
As I said, it probably works at the moment, under the current
conditions, but is fragile.

Cheers,
Andre

>>> +   spl->dt_name_offset = offsetof(struct boot_file_head, string_pool);
>>> +}
>>> +
>>>  int dram_init(void)
>>>  {
>>> struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
>>> @@ -904,6 +919,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>>>  int board_fit_config_name_match(const char *name)
>>>  {
>>> const char *best_dt_name = get_spl_dt_name();
>>> +   int ret;
>>>  
>>>  #ifdef CONFIG_DEFAULT_DEVICE_TREE
>>> if (best_dt_name == NULL)
>>> @@ -941,6 +957,15 @@ int board_fit_config_name_match(const char *name)
>>> }
>>>  #endif
>>>  
>>> -   return strcmp(name, best_dt_name);
>>> +   ret = strcmp(name, best_dt_name);
>>> +
>>> +   /*
>>> +* If one of the FIT configurations matches the most accurate DT name,
>>> +* update the SPL header to provide that DT name to U-Boot proper.
>>> +*/
>>> +   if (ret == 0)
>>> +   set_spl_dt_name(best_dt_name);
>>> +
>>> +   return ret;
>>>  }
>>>  #endif
>>>
>>
> 

Re: [PATCH 6/8] sunxi: board: Set fdtfile to match the DT chosen by SPL

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:

Hi,

> Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
> This meant that, regardless of the DT chosen by SPL (either by changing
> the header in the image or by the selection code at runtime), Linux
> always used the default DT.
> 
> By using the name from the SPL header (which, because of the previous
> commit, always matches the DT used by U-Boot proper), Linux also sees
> the same board as U-Boot/SPL, even if the boot script later loads a DT
> from disk.

I strongly frown upon proliferating the broken way of explicitly loading
a DT from somewhere, when the DT embedded in U-Boot should be all we
will ever need.
But making the selected DT available to U-Boot scripts doesn't really
hurt or prevent us from doing it properly, so:

> Signed-off-by: Samuel Holland 

One nit below, with that:
Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/sunxi/board.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index eaa40a1ea96..5457b28e135 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -870,6 +870,7 @@ static void setup_environment(const void *fdt)
>  
>  int misc_init_r(void)
>  {
> + const char *spl_dt_name;
>   uint boot;
>  
>   env_set("fel_booted", NULL);
> @@ -888,6 +889,16 @@ int misc_init_r(void)
>   env_set("mmc_bootdev", "1");
>   }
>  
> + /* Set fdtfile to match the FIT configuration chosen in SPL. */
> + spl_dt_name = get_spl_dt_name();
> + if (spl_dt_name) {
> + char *prefix = IS_ENABLED(CONFIG_ARM64) ? "allwinner/" : "";
> + char str[64];

The longest name (including the directory name) is 49 characters so far,
so let's hope that people don't go crazy with their DT names. Shall we
check the return value of snprintf() and at least complain? In contrast
to strncpy(), snprintf() is safe, but might still truncate the name.

Cheers,
Andre.

> +
> + snprintf(str, sizeof(str), "%s%s.dtb", prefix, spl_dt_name);
> + env_set("fdtfile", str);
> + }
> +
>   setup_environment(gd->fdt_blob);
>  
>  #ifdef CONFIG_USB_ETHER
> 

Re: [PATCH 4/8] sunxi: board: Add PinePhone DT selection logic

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:

Hi,

> There are two different publicly-released revisions of the PinePhone
> hardware, versions 1.1 and 1.2; and they need different device trees.
> Since some GPIO pins were rerouted, we can use that to distinguish
> between them.

Nice one. I once had a similar solution to differentiate between the
(otherwise very similar) Pinebook and Pine64-LTS.

> 
> Signed-off-by: Samuel Holland 

With the "else" down below removed:

Reviewed-by: Andre Przywara 

> ---
>  arch/arm/mach-sunxi/Kconfig |  7 +++
>  board/sunxi/board.c | 21 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index be0822bfb7d..8421f3b6854 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1010,4 +1010,11 @@ config PINE64_DT_SELECTION
> option, the device tree selection code specific to Pine64 which
> utilizes the DRAM size will be enabled.
>  
> +config PINEPHONE_DT_SELECTION
> + bool "Enable PinePhone device tree selection code"
> + depends on MACH_SUN50I
> + help
> +   Enable this option to automatically select the device tree for the
> +   correct PinePhone hardware revision during boot.
> +
>  endif
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index fb0d5bf4743..3d64ed18664 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -920,6 +921,26 @@ int board_fit_config_name_match(const char *name)
>   best_dt_name = "sun50i-a64-pine64";
>   }
>  #endif
> +#ifdef CONFIG_PINEPHONE_DT_SELECTION
> + else if (strstr(best_dt_name, "-pinephone")) {

I think to improve readability and increase robustness against future
changes you can lose the "else" here. Even if both selection methods
should be selected, only one will realistically match the strstr()
comparison.

> + /* Differentiate the PinePhone revisions by GPIO inputs. */
> + prcm_apb0_enable(PRCM_APB0_GATE_PIO);
> + sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_UP);
> + sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_INPUT);
> + udelay(100);
> +
> + /* PL6 is pulled low by the modem on v1.2. */
> + if (gpio_get_value(SUNXI_GPL(6)) == 0)
> + best_dt_name = "sun50i-a64-pinephone-1.2";
> + else
> + best_dt_name = "sun50i-a64-pinephone-1.1";
> +
> + sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_DISABLE);
> + sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_DISABLE);
> + prcm_apb0_disable(PRCM_APB0_GATE_PIO);

Looking forward, this should probably restore the former state, in case
some code elsewhere had enabled the PIO gate already. But for now, with
the current code state, this is fine.

Cheers,
Andre

> + }
> +#endif
> +
>   return strcmp(name, best_dt_name);
>  }
>  #endif
> 

Re: [PATCH 5/8] sunxi: board: Save the chosen DT name in the SPL header

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:
> This overwrites the name loaded from the SPL image. It will be different
> if there was previously no name provided, or if a more accurate name was
> determined by the board variant selection logic. This means that the DT> name 
> in the SPL header now always matches the DT appended to U-Boot.

That's a nice way of preserving all this fancy DT selection choices for
U-Boot proper!

> Signed-off-by: Samuel Holland 

One hint below, but nevertheless:

Reviewed-by: Andre Przywara 

> ---
>  board/sunxi/board.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 3d64ed18664..eaa40a1ea96 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -331,6 +331,21 @@ static const char *get_spl_dt_name(void)
>   return NULL;
>  }
>  
> +static void set_spl_dt_name(const char *name)
> +{
> + struct boot_file_head *spl = get_spl_header(SPL_ENV_HEADER_VERSION);
> +
> + if (spl == INVALID_SPL_HEADER)
> + return;
> +
> + /* Promote the header version for U-Boot proper, if needed. */
> + if (spl->spl_signature[3] < SPL_DT_HEADER_VERSION)
> + spl->spl_signature[3] = SPL_DT_HEADER_VERSION;
> +
> + strcpy((char *)>string_pool, name);

Let's hope nobody ever optimises the strcpy() routine, as this might
break (when doing unaligned accesses) on device memory, as in this case.

Cheers,
Andre.

> + spl->dt_name_offset = offsetof(struct boot_file_head, string_pool);
> +}
> +
>  int dram_init(void)
>  {
>   struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
> @@ -904,6 +919,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>  int board_fit_config_name_match(const char *name)
>  {
>   const char *best_dt_name = get_spl_dt_name();
> + int ret;
>  
>  #ifdef CONFIG_DEFAULT_DEVICE_TREE
>   if (best_dt_name == NULL)
> @@ -941,6 +957,15 @@ int board_fit_config_name_match(const char *name)
>   }
>  #endif
>  
> - return strcmp(name, best_dt_name);
> + ret = strcmp(name, best_dt_name);
> +
> + /*
> +  * If one of the FIT configurations matches the most accurate DT name,
> +  * update the SPL header to provide that DT name to U-Boot proper.
> +  */
> + if (ret == 0)
> + set_spl_dt_name(best_dt_name);
> +
> + return ret;
>  }
>  #endif
> 

Re: [PATCH 3/8] sunxi: board: Simplify Pine A64 DT selection logic

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:
> Instead of using an entirely separate matching algorithm, simply update
> the name of the DT we want to match. Enabling this logic does not depend
> on the FIT config name, only on the initial guess of the board name.

Yeah, clever solution. The original code was indeed quite confusing,
partly because it tried to desperately save on code size. Turns out your
solution is much smaller now ;-)

> Importantly, the initial guess must be "sun50i-a64-pine64-plus", because
> otherwise the logic would trigger when "sun50i-a64-pine64-lts" was
> written to the SPL header.

Ah, good catch.

> 
> Signed-off-by: Samuel Holland 

One nit below, with that:

Reviewed-by: Andre Przywara 

> ---
>  board/sunxi/board.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 5c9b811f27a..fb0d5bf4743 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -914,14 +914,10 @@ int board_fit_config_name_match(const char *name)
>   return 0;
>   }
>  #ifdef CONFIG_PINE64_DT_SELECTION
> -/* Differentiate the two Pine64 board DTs by their DRAM size. */
> - if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
> - if ((gd->ram_size > 512 * 1024 * 1024))
> - return !strstr(name, "plus");
> - else
> - return !!strstr(name, "plus");
> - } else {
> - return strcmp(name, best_dt_name);
> + else if (strstr(best_dt_name, "-pine64-plus")) {

I think you don't need this "else" here, as the "if" part returns
already. Makes this even easier to read.

Cheers,
Andre.

> + /* Differentiate the Pine A64 boards by their DRAM size. */
> + if ((gd->ram_size == 512 * 1024 * 1024))
> + best_dt_name = "sun50i-a64-pine64";
>   }
>  #endif
>   return strcmp(name, best_dt_name);
> 

Re: [PATCH 2/8] sunxi: board: Add a helper to get the SPL DT name

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:
> This moves the validity checking and typecasts all to one place away
> from the string comparison logic, and it detangles the compile-time
> and runtime control flow.
> 
> The new helper will also be used by U-Boot proper in a future commit.
> 
> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Thanks,
Andre

> ---
>  board/sunxi/board.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 674e6816d2d..5c9b811f27a 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -319,6 +319,17 @@ static struct boot_file_head * get_spl_header(uint8_t 
> req_version)
>   return spl;
>  }
>  
> +static const char *get_spl_dt_name(void)
> +{
> + struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
> +
> + /* Check if there is a DT name stored in the SPL header. */
> + if (spl != INVALID_SPL_HEADER && spl->dt_name_offset)
> + return (char *)spl + spl->dt_name_offset;
> +
> + return NULL;
> +}
> +
>  int dram_init(void)
>  {
>   struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
> @@ -891,20 +902,17 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>  #ifdef CONFIG_SPL_LOAD_FIT
>  int board_fit_config_name_match(const char *name)
>  {
> - struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
> - const char *best_dt_name = (const char *)spl;
> + const char *best_dt_name = get_spl_dt_name();
>  
> - /* Check if there is a DT name stored in the SPL header and use that. */
> - if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
> - best_dt_name += spl->dt_name_offset;
> - } else {
>  #ifdef CONFIG_DEFAULT_DEVICE_TREE
> + if (best_dt_name == NULL)
>   best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
> -#else
> - return 0;
>  #endif
> - };
>  
> + if (best_dt_name == NULL) {
> + /* No DT name was provided, so accept the first config. */
> + return 0;
> + }
>  #ifdef CONFIG_PINE64_DT_SELECTION
>  /* Differentiate the two Pine64 board DTs by their DRAM size. */
>   if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
> 

Re: [PATCH 1/8] sunxi: board: Use a more descriptive variable name

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:
> The variable "cmp_str" always leaves me wondering if it is the DT name
> of the current board (yes) or DT name in the FIT config entry (no).
> 
> In preparation for expanding the functionality here, rename it to
> something that obviously means "this is the DT name we are looking for".
> 
> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/sunxi/board.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 71e2b758a3e..674e6816d2d 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -892,14 +892,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>  int board_fit_config_name_match(const char *name)
>  {
>   struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
> - const char *cmp_str = (const char *)spl;
> + const char *best_dt_name = (const char *)spl;
>  
>   /* Check if there is a DT name stored in the SPL header and use that. */
>   if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
> - cmp_str += spl->dt_name_offset;
> + best_dt_name += spl->dt_name_offset;
>   } else {
>  #ifdef CONFIG_DEFAULT_DEVICE_TREE
> - cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
> + best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
>  #else
>   return 0;
>  #endif
> @@ -907,15 +907,15 @@ int board_fit_config_name_match(const char *name)
>  
>  #ifdef CONFIG_PINE64_DT_SELECTION
>  /* Differentiate the two Pine64 board DTs by their DRAM size. */
> - if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
> + if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
>   if ((gd->ram_size > 512 * 1024 * 1024))
>   return !strstr(name, "plus");
>   else
>   return !!strstr(name, "plus");
>   } else {
> - return strcmp(name, cmp_str);
> + return strcmp(name, best_dt_name);
>   }
>  #endif
> - return strcmp(name, cmp_str);
> + return strcmp(name, best_dt_name);
>  }
>  #endif
> 

Re: [PATCH v3 4/4] arm64: Trap non-PIE builds early if starting from wrong address

[André Przywara]

On 10/09/2020 13:38, Michal Simek wrote:
> 
> 
> On 09. 09. 20 19:07, Edgar E. Iglesias wrote:
>> From: "Edgar E. Iglesias" 
>>
>> Trap non-PIE builds early if the start address doesn't match
>> between run-time and link-time. This will trap the startup
>> sequence rather than letting it run into obscure errors.
>>
>> Signed-off-by: Edgar E. Iglesias 
>> ---
>>  arch/arm/cpu/armv8/start.S | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>> index e5c2856cf5..39e1b842c4 100644
>> --- a/arch/arm/cpu/armv8/start.S
>> +++ b/arch/arm/cpu/armv8/start.S
>> @@ -101,6 +101,19 @@ pie_skip_reloc:
>>  cmp x2, x3
>>  b.lopie_fix_loop
>>  pie_fixup_done:
>> +#else
>> +adr x0, _start
>> +ldr x1, _TEXT_BASE
>> +cmp x0, x1
>> +beq 1f
>> +0:
>> +/*
>> + * FATAL, can't continue.
>> + * U-Boot needs to start executing at CONFIG_SYS_TEXT_BASE.
>> + */
>> +wfi
>> +b   0b
>> +1:
>>  #endif
>>  
>>  #ifdef CONFIG_SYS_RESET_SCTRL
>>
> 
> NACK for this.
> 
> 1. It breaks SPL flow because CONFIG_SYS_TEXT_BASE is text base for
> U-Boot proper
> 2. It likely also breaks TPL flow for the same reason
> 
> 3. And last thing is that this code is used only for U-Boot proper.
> .globl_TEXT_BASE
> _TEXT_BASE:
>   .quad   CONFIG_SYS_TEXT_BASE
> 
> The fixes are below. Point 3 should be likely be in separate patch
> because it is unrelated.

So if this patch causes issues, can't we just drop it? I mean right now
you will probably just crash anyway if you load it at the wrong address,
but maybe late enough that you get more hints or even some output.

Now this patch makes sure that you don't get anything, so I don't see
how this is really improving the situation. It seems like a case of
"don't fix things that ain't broken".

Cheers,
Andre


> 
> Thanks,
> Michal
> 
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index b37dbabf4d42..cdc609e873fc 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -33,10 +33,11 @@ _start:
> 
> .align 3
> 
> +#if !(defined(CONFIG_SPL_BUILD) || defined(CONFIG_TPL_BUILD))
>  .globl _TEXT_BASE
>  _TEXT_BASE:
> .quad   CONFIG_SYS_TEXT_BASE
> -
> +#endif
>  /*
>   * These are defined in the linker script.
>   */
> @@ -102,6 +103,7 @@ pie_skip_reloc:
> b.lopie_fix_loop
>  pie_fixup_done:
>  #else
> +#if !(defined(CONFIG_SPL_BUILD) || defined(CONFIG_TPL_BUILD))
> adr x0, _start
> ldr x1, _TEXT_BASE
> cmp x0, x1
> @@ -115,6 +117,7 @@ pie_fixup_done:
> b   0b
>  1:
>  #endif
> +#endif
> 
>  #ifdef CONFIG_SYS_RESET_SCTRL
> bl reset_sctrl
> 

Re: [PATCH 0/8] PinePhone automatic device tree selection

[André Przywara]

On 03/09/2020 06:07, Samuel Holland wrote:

Hi Samuel,

> This patch series implements a feature to automatically choose the
> right PinePhone device tree by probing the hardware. It then extends
> the functionality to pass the chosen DTB name to the boot command.
> Finally, I add device trees and a defconfig for the PinePhone.
> 
> I'm aware that Andre has concerns about updating the device tree files.
> It would be unfortunate for this to block new hardware support.

I agree that it shouldn't block it.

> Since
> the device trees are primarily maintained in the Linux repository, and
> only copied here, I believe compatibility concerns should be directed
> there, not here.

Sigh. I tried that there, multiple times, and was basically dismissed.
IIRC the main argument was that we (as the sunxi community) do not have
the resources to pull off something like compatible DTs. The DTs are
being created and written as we go, so maintaining forward compatibility
is not something the Linux maintainers wanted to subscribe to.
And while I see that's *some* extra effort, I argued that it's worth it,
even providing solutions. Otherwise I am afraid that we end up in the
embedded rabbit hole that we see today, where dozens of images are
traded around, even though there are generic distributions available.

We parted by agreeing on putting those necessary DT changes into U-Boot
instead. Commit ababb5920e899 is one example of this. I tried to prevent
further changes, but failed.

> In any case, the first 6 patches can be merged
> independently, so I request that they be merged even if patches 7-8 are
> not. I am mainly including the last two patches for ease of testing.

So I have some easy patches that improve DT compatibility, I guess we
can just apply them later. The most prominent issue is the change of the
RTC compatible name. This seems to cost us the RTC (bearable?) and, in
turn, the debouncing feature of the GPIO controller (through the newly
introduced clock in the RTC).
There seem to be more issues that popped up in testing. I guess we would
need to define some supported kernels, and test them. The effort for
this depends on how far back we want to support Linux kernels and with
what feature set. I ran a headless board fine here with Ubuntu's 18.04
original kernel, which is 4.15 based. I might concede to give this up,
if needed, to go back to only 4.19 (Debian), or maybe 4.18 (Ubuntu
18.04.2 HWE kernel).

I will have a look at the other patches later. It seems like you jump
through some hoops to be able to set fdtfile in U-Boot proper later? I
consider this conceptually dodgy ($fdtcontroladdr should be all you
need), but don't care enough, as it does not seem to break things.

Cheers,
Andre

> Samuel Holland (8):
>   sunxi: board: Use a more descriptive variable name
>   sunxi: board: Add a helper to get the SPL DT name
>   sunxi: board: Simplify Pine A64 DT selection logic
>   sunxi: board: Add PinePhone DT selection logic
>   sunxi: board: Save the chosen DT name in the SPL header
>   sunxi: board: Set fdtfile to match the DT chosen by SPL
>   sunxi: DT: A64: update device tree files
>   sunxi: a64: Add a defconfig for the PinePhone
> 
>  arch/arm/dts/Makefile |   4 +
>  arch/arm/dts/axp803.dtsi  |  82 +--
>  arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++-
>  arch/arm/dts/sun50i-a64-bananapi-m64.dts  | 118 ++--
>  arch/arm/dts/sun50i-a64-cpu-opp.dtsi  |  75 +++
>  arch/arm/dts/sun50i-a64-nanopi-a64.dts|  70 +--
>  .../dts/sun50i-a64-oceanic-5205-5inmfd.dts|  31 +-
>  arch/arm/dts/sun50i-a64-olinuxino-emmc.dts|  12 +-
>  arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++--
>  arch/arm/dts/sun50i-a64-orangepi-win.dts  | 127 +++--
>  arch/arm/dts/sun50i-a64-pine64-lts.dts|   7 +-
>  arch/arm/dts/sun50i-a64-pine64-plus.dts   |  52 +-
>  arch/arm/dts/sun50i-a64-pine64.dts|  97 ++--
>  arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi  |  17 -
>  arch/arm/dts/sun50i-a64-pinebook.dts  | 237 ++--
>  arch/arm/dts/sun50i-a64-pinephone-1.0.dts |  11 +
>  arch/arm/dts/sun50i-a64-pinephone-1.1.dts |  30 +
>  arch/arm/dts/sun50i-a64-pinephone-1.2.dts |  40 ++
>  arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++
>  arch/arm/dts/sun50i-a64-pinetab.dts   | 460 +++
>  arch/arm/dts/sun50i-a64-sopine-baseboard.dts  | 113 ++--
>  arch/arm/dts/sun50i-a64-sopine.dtsi   |  69 +--
>  arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi   |  41 --
>  arch/arm/dts/sun50i-a64-teres-i.dts   | 138 -
>  arch/arm/dts/sun50i-a64.dtsi  | 532 ++
>  arch/arm/mach-sunxi/Kconfig   |   7 +
>  board/sunxi/board.c   |  97 +++-
>  configs/pinephone_defconfig   |  12 +
>  include/dt-bindings/clock/sun50i-a64-ccu.h|   4 +-
>  include/dt-bindings/clock/sun8i-de2.h |   3 +
>  

Re: [PATCH v2 1/3] arm64: Mention 4K aligned load addresses in the PIE Kconfig help

[André Przywara]

On 04/09/2020 19:42, Stephen Warren wrote:
> On 9/4/20 3:07 AM, Edgar E. Iglesias wrote:
>> From: "Edgar E. Iglesias" 
>>
>> Mention the requirement of 4K aligned load addresses in the
>> help section for the POSITION_INDEPENDENT option.
>>
>> Suggested-by: Michal Simek 
>> Signed-off-by: Edgar E. Iglesias 
>> ---
>>  arch/arm/Kconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index f30c2639ec..c144c08612 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -21,6 +21,9 @@ config POSITION_INDEPENDENT
>>information that is embedded in the binary to support U-Boot
>>relocating itself to the top-of-RAM later during execution.
>>  
>> +  When this option is enabled, U-Boot needs to be loaded at a
>> +  4K aligned address.
> 
> I don't believe this restriction should be documented as part of
> POSITION_INDEPENDENT; the restriction always exists at least for 64-bit
> ARM, since arch/arm/lib/relocate_64.S relocate_code uses the same
> assembly sequence that imposes this restriction, and IIUC that code is
> unconditionally used.

While this is true, the difference is that without POSITION_INDEPENDENT
the alignment is easily determined by the hardcoded load address. So we
should actually have a build time check on this.

With POSITION_INDEPENDENT, however, the load address is only known at
runtime (somewhat under the user's control, if you like). So a warning
or hint here might be useful. But maybe it should be noted as a general
restriction in the paragraph above:
" ... from almost any address" => "from almost any 4K aligned address"

Cheers,
Andre.

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

[André Przywara]

On 03/09/2020 14:41, Michal Simek wrote:
> 
> 
> On 02. 09. 20 20:59, André Przywara wrote:
>> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
>>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>>>> On 02/09/2020 15:53, Edgar E. Iglesias wrote:
>>>>> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
>>>>>> On 02/09/2020 12:15, Michal Simek wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>
>>>>>>> From: "Edgar E. Iglesias" 
>>>>>>>
>>>>>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>>>>>> compilation error is shown:
>>>>>>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>>>>>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>>>>>>> defined in .bss_start section in u-boot.
>>>>>>>
>>>>>>> It is caused by adr instruction which permits the calculation of any 
>>>>>>> byte
>>>>>>> address within +- 1MB of the current PC.
>>>>>>> Because U-Boot is bigger then 1MB calculation is failing.
>>>>>>>
>>>>>>> The patch is using adrp/add instructions where adrp shifts a signed, 
>>>>>>> 21-bit
>>>>>>> immediate left by 12 bits (4k page), adds it to the value of the program
>>>>>>> counter with the bottom 12 bits cleared to zero. Then add instruction
>>>>>>> provides the lower 12 bits which is offset within 4k page.
>>>>>>> These two instructions together compose full 32bit offset which should 
>>>>>>> be
>>>>>>> more then enough to cover the whole u-boot size.
>>>>>>>
>>>>>>> Signed-off-by: Edgar E. Iglesias 
>>>>>>> Signed-off-by: Michal Simek 
>>>>>>
>>>>>> It's a bit scary that you need more than 1MB, but indeed what you do
>>>>>> below is the canonical pattern to get the full range of PC relative
>>>>>> addressing (this is used heavily in Trusted Firmware, for instance).
>>>>>>
>>>>>> The only thing to keep in mind is that this assumes that the load
>>>>>> address of the binary is 4K aligned, so that the low 12 bits of the
>>>>>> symbol stay the same. I wonder if we should enforce this somehow? But
>>>>>> the load address is not controlled by the build process (the whole
>>>>>> purpose of PIE), so that's not doable just in the build system?
>>>>>
>>>>> There shouldn't be any need for 4K alignment. Could you elaborate on
>>>>> why you think there is?
>>>>
>>>> That seems to be slightly tricky, and I tried to get some confirmation,
>>>> but here goes my reasoning. Maybe you can confirm this:
>>>>
>>>> - adrp takes the relative offset, but only of the upper 20 bits (because
>>>> that's all we can encode). It clears the lower 12 bits of the register.
>>>> - the "add" is not PC relative anymore, so it just takes the lower 12
>>>> bits of the "absolute" linker symbol.
>>>
>>> I was under the impression that this would use a PC-relative lower 12bit
>>> relocation but you are correct. I dissasembled the result:
>>>
>>>   40:   9142add x2, x2, #0x0
>>> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
>>>
>>>
>>>
>>>
>>>
>>>> So this assumes that the lower 12 bits of the actual address in memory
>>>> and the lower 12 bits of the linker's view match.
>>>> An example:
>>>> 00024: adrp x0, SYMBOL
>>>> 00028: add  x0, x0, :lo12:SYMBOL
>>>>
>>>> SYMBOL:
>>>> 42058: ...
>>>>
>>>> The toolchain will generate:
>>>>adrp x0, #0x42; add x0, x0, #0x058
>>>>
>>>> Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
>>>> 0x80042858.
>>>> The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
>>>> The add will just add 0x58, so you end up with x0 being 0x80042058,
>>>> which is not the right address.
>>>>
>>>> Does this make sense?
>>>
>>>
>>> Ye

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

[André Przywara]

On 03/09/2020 14:35, Michal Simek wrote:
> 
> 
> On 02. 09. 20 18:34, Stephen Warren wrote:
>> On 9/2/20 5:15 AM, Michal Simek wrote:
>>> From: "Edgar E. Iglesias" 
>>>
>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>> compilation error is shown:
>>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>>> defined in .bss_start section in u-boot.
>>>
>>> It is caused by adr instruction which permits the calculation of any byte
>>> address within +- 1MB of the current PC.
>>> Because U-Boot is bigger then 1MB calculation is failing.
>>>
>>> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
>>> immediate left by 12 bits (4k page), adds it to the value of the program
>>> counter with the bottom 12 bits cleared to zero. Then add instruction
>>> provides the lower 12 bits which is offset within 4k page.
>>> These two instructions together compose full 32bit offset which should be
>>> more then enough to cover the whole u-boot size.
>>
>>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>>
>>> @@ -67,8 +67,10 @@ pie_fixup:
>>> adr x0, _start  /* x0 <- Runtime value of _start */
>>> ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
>>> sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>>> -   adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> -   adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> +   add x2, x2, #:lo12:__rel_dyn_start
>>> +   adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   add x3, x3, #:lo12:__rel_dyn_end
>>>  pie_fix_loop:
>>> ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
>>> ldr x4, [x2], #8/* x4 <- addend */
>>
>> There are likely a bunch of other places in the code that need updating
>> too; take a look at commit 49e93875a62f "arm64: support running at addr
>> other than linked to" (which introduced the code above) to find other
>> places with similar instruction sequences that almost certainly need
>> updating.
>>
> 
> I didn't hit any issue to have a need to update them. Definitely worth
> to check that locations too.

So I thought the same, so I checked at least this file. And while there
are other "adr" instructions, they only go to nearby labels, so don't
need to be pumped up.
But I will try to grep for more cases as well.

Cheers,
Andre

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

[André Przywara]

On 02/09/2020 16:25, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>> On 02/09/2020 15:53, Edgar E. Iglesias wrote:
>>> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
 On 02/09/2020 12:15, Michal Simek wrote:
>>
>> Hi,
>>

> From: "Edgar E. Iglesias" 
>
> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
> compilation error is shown:
> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
> defined in .bss_start section in u-boot.
>
> It is caused by adr instruction which permits the calculation of any byte
> address within +- 1MB of the current PC.
> Because U-Boot is bigger then 1MB calculation is failing.
>
> The patch is using adrp/add instructions where adrp shifts a signed, 
> 21-bit
> immediate left by 12 bits (4k page), adds it to the value of the program
> counter with the bottom 12 bits cleared to zero. Then add instruction
> provides the lower 12 bits which is offset within 4k page.
> These two instructions together compose full 32bit offset which should be
> more then enough to cover the whole u-boot size.
>
> Signed-off-by: Edgar E. Iglesias 
> Signed-off-by: Michal Simek 

 It's a bit scary that you need more than 1MB, but indeed what you do
 below is the canonical pattern to get the full range of PC relative
 addressing (this is used heavily in Trusted Firmware, for instance).

 The only thing to keep in mind is that this assumes that the load
 address of the binary is 4K aligned, so that the low 12 bits of the
 symbol stay the same. I wonder if we should enforce this somehow? But
 the load address is not controlled by the build process (the whole
 purpose of PIE), so that's not doable just in the build system?
>>>
>>> There shouldn't be any need for 4K alignment. Could you elaborate on
>>> why you think there is?
>>
>> That seems to be slightly tricky, and I tried to get some confirmation,
>> but here goes my reasoning. Maybe you can confirm this:
>>
>> - adrp takes the relative offset, but only of the upper 20 bits (because
>> that's all we can encode). It clears the lower 12 bits of the register.
>> - the "add" is not PC relative anymore, so it just takes the lower 12
>> bits of the "absolute" linker symbol.
> 
> I was under the impression that this would use a PC-relative lower 12bit
> relocation but you are correct. I dissasembled the result:
> 
>   40:   9142add x2, x2, #0x0
> 40: R_AARCH64_ADD_ABS_LO12_NC   __rel_dyn_start
> 
> 
> 
> 
> 
>> So this assumes that the lower 12 bits of the actual address in memory
>> and the lower 12 bits of the linker's view match.
>> An example:
>> 00024: adrp x0, SYMBOL
>> 00028: add  x0, x0, :lo12:SYMBOL
>>
>> SYMBOL:
>> 42058: ...
>>
>> The toolchain will generate:
>>  adrp x0, #0x42; add x0, x0, #0x058
>>
>> Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
>> 0x80042858.
>> The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
>> The add will just add 0x58, so you end up with x0 being 0x80042058,
>> which is not the right address.
>>
>> Does this make sense?
> 
> 
> Yes, it makes sense.
> 
>>
>>> Perhaps the commit message is a little confusing. The toolchain will
>>> compute the pc-relative offset from this particular location to the
>>> symbol and apply the relocations accordingly.
>>
>> Yes, but the PC relative offset applies only to the upper 20 bits,
>> because it's only adrp that has PC relative semantics.
>>
>>

 Shall we at least document this? I guess typical load address are
 actually quite well aligned, so it might not be an issue in practice.

> 
> Yes, probably worth documenting and perhaps an early bail-out if it's not
> the case...

Documenting sounds good, Kconfig might be a good place, as Michal suggested.

Bail out: I thought about that, it's very easy to detect at runtime, but
what then? This is really early, so you could just enter a WFI loop, and
hope for someone to connect the dots?
Or can you think of any other way of communicating with the user?

Cheers,
Andre

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

[André Przywara]

On 02/09/2020 15:53, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
>> On 02/09/2020 12:15, Michal Simek wrote:

Hi,

>>
>>> From: "Edgar E. Iglesias" 
>>>
>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>> compilation error is shown:
>>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
>>> defined in .bss_start section in u-boot.
>>>
>>> It is caused by adr instruction which permits the calculation of any byte
>>> address within +- 1MB of the current PC.
>>> Because U-Boot is bigger then 1MB calculation is failing.
>>>
>>> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
>>> immediate left by 12 bits (4k page), adds it to the value of the program
>>> counter with the bottom 12 bits cleared to zero. Then add instruction
>>> provides the lower 12 bits which is offset within 4k page.
>>> These two instructions together compose full 32bit offset which should be
>>> more then enough to cover the whole u-boot size.
>>>
>>> Signed-off-by: Edgar E. Iglesias 
>>> Signed-off-by: Michal Simek 
>>
>> It's a bit scary that you need more than 1MB, but indeed what you do
>> below is the canonical pattern to get the full range of PC relative
>> addressing (this is used heavily in Trusted Firmware, for instance).
>>
>> The only thing to keep in mind is that this assumes that the load
>> address of the binary is 4K aligned, so that the low 12 bits of the
>> symbol stay the same. I wonder if we should enforce this somehow? But
>> the load address is not controlled by the build process (the whole
>> purpose of PIE), so that's not doable just in the build system?
> 
> There shouldn't be any need for 4K alignment. Could you elaborate on
> why you think there is?

That seems to be slightly tricky, and I tried to get some confirmation,
but here goes my reasoning. Maybe you can confirm this:

- adrp takes the relative offset, but only of the upper 20 bits (because
that's all we can encode). It clears the lower 12 bits of the register.
- the "add" is not PC relative anymore, so it just takes the lower 12
bits of the "absolute" linker symbol.
So this assumes that the lower 12 bits of the actual address in memory
and the lower 12 bits of the linker's view match.
An example:
00024: adrp x0, SYMBOL
00028: add  x0, x0, :lo12:SYMBOL

SYMBOL:
42058: ...

The toolchain will generate:
adrp x0, #0x42; add x0, x0, #0x058

Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at
0x80042858.
The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000.
The add will just add 0x58, so you end up with x0 being 0x80042058,
which is not the right address.

Does this make sense?

> Perhaps the commit message is a little confusing. The toolchain will
> compute the pc-relative offset from this particular location to the
> symbol and apply the relocations accordingly.

Yes, but the PC relative offset applies only to the upper 20 bits,
because it's only adrp that has PC relative semantics.

Cheers,
Andre

>>
>> Shall we at least document this? I guess typical load address are
>> actually quite well aligned, so it might not be an issue in practice.
>>
>> Cheers,
>> Andre
>>
>>> ---
>>>
>>>  arch/arm/cpu/armv8/start.S | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
>>> index 002698b501c3..52cf1230c205 100644
>>> --- a/arch/arm/cpu/armv8/start.S
>>> +++ b/arch/arm/cpu/armv8/start.S
>>> @@ -67,8 +67,10 @@ pie_fixup:
>>> adr x0, _start  /* x0 <- Runtime value of _start */
>>> ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
>>> sub x9, x0, x1  /* x9 <- Run-vs-link offset */
>>> -   adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> -   adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
>>> +   add x2, x2, #:lo12:__rel_dyn_start
>>> +   adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
>>> +   add x3, x3, #:lo12:__rel_dyn_end
>>>  pie_fix_loop:
>>> ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
>>> ldr x4, [x2], #8/* x4 <- addend */
>>>
>>

Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y

[André Przywara]

On 02/09/2020 12:15, Michal Simek wrote:

Hi,

> From: "Edgar E. Iglesias" 
> 
> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
> compilation error is shown:
> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
> defined in .bss_start section in u-boot.
> 
> It is caused by adr instruction which permits the calculation of any byte
> address within +- 1MB of the current PC.
> Because U-Boot is bigger then 1MB calculation is failing.
> 
> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit
> immediate left by 12 bits (4k page), adds it to the value of the program
> counter with the bottom 12 bits cleared to zero. Then add instruction
> provides the lower 12 bits which is offset within 4k page.
> These two instructions together compose full 32bit offset which should be
> more then enough to cover the whole u-boot size.
> 
> Signed-off-by: Edgar E. Iglesias 
> Signed-off-by: Michal Simek 

It's a bit scary that you need more than 1MB, but indeed what you do
below is the canonical pattern to get the full range of PC relative
addressing (this is used heavily in Trusted Firmware, for instance).

The only thing to keep in mind is that this assumes that the load
address of the binary is 4K aligned, so that the low 12 bits of the
symbol stay the same. I wonder if we should enforce this somehow? But
the load address is not controlled by the build process (the whole
purpose of PIE), so that's not doable just in the build system?

Shall we at least document this? I guess typical load address are
actually quite well aligned, so it might not be an issue in practice.

Cheers,
Andre

> ---
> 
>  arch/arm/cpu/armv8/start.S | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 002698b501c3..52cf1230c205 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -67,8 +67,10 @@ pie_fixup:
>   adr x0, _start  /* x0 <- Runtime value of _start */
>   ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
>   sub x9, x0, x1  /* x9 <- Run-vs-link offset */
> - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
> - adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
> + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
> + add x2, x2, #:lo12:__rel_dyn_start
> + adrpx3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
> + add x3, x3, #:lo12:__rel_dyn_end
>  pie_fix_loop:
>   ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
>   ldr x4, [x2], #8/* x4 <- addend */
> 

Re: [PATCH] Makefile: sunxi: Don't use binman to build ATF image

[André Przywara]

On 07/08/2020 16:44, Simon Glass wrote:
> At present with sunxi 64-bit, the Makefile builds
> u-boot-sunxi-with-spl.bin and then binman overwrites it with its own
> version. But the binman definition lacks some parts, in particular
> BL31.
> 
> For now, work around this with a hack.

Many thanks for providing this! Indeed it fixes the immediate problem
for me. Tested on BananaPi-M64. Also compared the binaries for a 32-bit
BPi-M1 build with and w/o the fix, and found them identical (with
reproducible build magic).

> Signed-off-by: Simon Glass 

Tested-by: Andre Przywara 

Cheers,
Andre

> Fixes: 42b18df80fd ("x86: Makefile: Drop explicit targets built by binman")
> ---
> 
>  Makefile | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 2629a741f1e..4483a9bc8a3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1024,9 +1024,13 @@ PHONY += inputs
>  inputs: $(INPUTS-y)
>  
>  all: .binman_stamp inputs
> + # Hack for sunxi which doesn't have a proper binman definition for
> + # 64-bit boards
> +ifneq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64),yy)
>  ifeq ($(CONFIG_BINMAN),y)
>   $(call if_changed,binman)
>  endif
> +endif
>  
>  # Timestamp file to make sure that binman always runs
>  .binman_stamp: FORCE
> 

Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)

[André Przywara]

On 05/08/2020 16:05, Simon Glass wrote:
> Hi André,
> 
> On Wed, 5 Aug 2020 at 08:20, André Przywara  wrote:
>>
>> On 19/07/2020 20:56, Simon Glass wrote:
>>
>> Hi,
>>
>>> On x86 various files that need to be created by binman. It does not make
>>> sense to enumerate these in the Makefile. They are described in the
>>> configuration (devicetree) for each board and we can simply run binman
>>> (always) to generate them.
>>>
>>> Update the Makefile to have a separate, final step which runs binman,
>>> once all input dependencies are present.
>>>
>>> This avoid sprinkling the Makefile with arch-specific code.
>>
>> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
>> When building current master, the Trusted Firmware binary does not make
>> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
>> won't get very far without BL31. To me it looks like we combine
>> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
>> bl31.bin.
>>
>> I bisected down into the hunks of this patch here, and by reverting just
>> hunk #3 (the one introducing .binman_stamp) it works again.
>> My knowledge of the U-Boot build system is somewhat limited, so I don't
>> immediately see the problem or a fix.
>>
>> A simple way to verify a build is complete would be:
>> $ strings u-boot-sunxi-with-spl.bin | grep BL31
>> If it reports some lines, TF-A is included and it would work correctly.
>> If it comes back empty, TF-A is missing and we won't boot.
>>
>> I would be grateful for any insights!
> 
> Thanks for the info. Which board is this?

I happened to see this on bananapi_m64_defconfig, but any arm64 sunxi
board should be affected.

Thanks,
Andre

sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)

[André Przywara]

On 19/07/2020 20:56, Simon Glass wrote:

Hi,

> On x86 various files that need to be created by binman. It does not make
> sense to enumerate these in the Makefile. They are described in the
> configuration (devicetree) for each board and we can simply run binman
> (always) to generate them.
> 
> Update the Makefile to have a separate, final step which runs binman,
> once all input dependencies are present.
> 
> This avoid sprinkling the Makefile with arch-specific code.

it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
When building current master, the Trusted Firmware binary does not make
it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
won't get very far without BL31. To me it looks like we combine
u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
bl31.bin.

I bisected down into the hunks of this patch here, and by reverting just
hunk #3 (the one introducing .binman_stamp) it works again.
My knowledge of the U-Boot build system is somewhat limited, so I don't
immediately see the problem or a fix.

A simple way to verify a build is complete would be:
$ strings u-boot-sunxi-with-spl.bin | grep BL31
If it reports some lines, TF-A is included and it would work correctly.
If it comes back empty, TF-A is missing and we won't boot.

I would be grateful for any insights!

Cheers,
Andre

> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Drop rockchip changes which should not be in this patch
> 
>  Makefile | 63 +---
>  1 file changed, 14 insertions(+), 49 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 0147d9d49b..b4b5b10813 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -921,16 +921,6 @@ INPUTS-$(CONFIG_REMAKE_ELF) += u-boot.elf
>  INPUTS-$(CONFIG_EFI_APP) += u-boot-app.efi
>  INPUTS-$(CONFIG_EFI_STUB) += u-boot-payload.efi
>  
> -ifneq ($(CONFIG_HAS_ROM),)
> -ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
> -INPUTS-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
> -endif
> -endif
> -
> -ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
> -INPUTS-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
> -endif
> -
>  # Build a combined spl + u-boot image for sunxi
>  ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
>  INPUTS-y += u-boot-sunxi-with-spl.bin
> @@ -961,6 +951,10 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
>  INPUTS-y += u-boot-rockchip.bin
>  endif
>  
> +INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
> + $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
> + $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin)
> +
>  LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>  
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> @@ -1018,7 +1012,14 @@ cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
>  PHONY += inputs
>  inputs: $(INPUTS-y)
>  
> -all: inputs
> +all: .binman_stamp inputs
> +ifeq ($(CONFIG_BINMAN),y)
> + $(call if_changed,binman)
> +endif
> +
> +# Timestamp file to make sure that binman always runs
> +.binman_stamp: FORCE
> + @touch $@
>  
>  ifeq ($(CONFIG_DEPRECATED),y)
>   $(warning "You have deprecated configuration options enabled in your 
> .config! Please check your configuration.")
> @@ -1311,7 +1312,7 @@ quiet_cmd_binman = BINMAN  $@
>  cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
>  --toolpath $(objtree)/tools \
>   $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
> - build -u -d u-boot.dtb -O . -m \
> + build -u -d u-boot.dtb -O . -m --allow-missing \
>   -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
>   $(BINMAN_$(@F))
>  
> @@ -1588,27 +1589,11 @@ u-boot-br.bin: u-boot FORCE
>  endif
>  endif
>  
> -# x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
> -# reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
> -# the middle. This is handled by binman based on an image description in the
> -# board's device tree.
> -ifneq ($(CONFIG_HAS_ROM),)
> -rom: u-boot.rom FORCE
> -
> -refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE
> - $(call if_changed,copy)
> -
>  quiet_cmd_ldr = LD  $@
>  cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
>  $(filter-out FORCE,$^) -o $@
>  
> -rom-deps := u-boot.bin
>  ifdef CONFIG_X86
> -rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
> - $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
> - $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
> - $(if $(CONFIG_HAVE_REFCODE),refcode.bin)
> -
>  OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16
>  u-boot-x86-start16.bin: u-boot FORCE
>   $(call if_changed,objcopy)
> @@ -1617,24 +1602,7 @@ OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j 
> .resetvec
>  u-boot-x86-reset16.bin: u-boot FORCE
>   $(call if_changed,objcopy)
>  
> -else # !CONFIG_X86
> 

Re: [PATCH 6/8] arm: dts: Sync the sun50i-a64.dtsi from Linux 5.8-rc1

[André Przywara]

On 27/07/2020 14:16, Heinrich Schuchardt wrote:

Hi Peter, Heinrich,

> On 26.07.20 12:17, Peter Robinson wrote:
>> On Thu, Jul 23, 2020 at 12:15 AM André Przywara  
>> wrote:
>>>
>>> On 22/07/2020 15:18, Peter Robinson wrote:
>>>> Sync the Allwinner A64 sun50i-a64.dtsi from Linux.
>>>
>>> Hi Peter,
>>>
>>> thanks for your series!
>>>
>>> While this looks mostly straight-forward, the problem is that this patch
>>> here affects all Allwinner boards. And for them it breaks older kernels,
>>> which cannot cope with some of the changed bindings or nodes.
>>> Your patches up until here are fine, since they only add nodes and
>>> properties, but this update changes nodes, some in a non-compatible way.
>>>
>>> Examples are dropping the "syscon" compatible (which requires 4.18 to
>>> know about the new compatible string) and the dropping of
>>> internal-osc-clk and the connected RTC change. This breaks any kernels
>>> that don't know about the third RTC clock (< 2>) or the new
>>> compatible string (introduced in 4.20). Similar effects show up in other
>>> OSes.
>>
>> The 4.18 kernel is over 2 years old. How many users are going to
>> actively upgrade U-Boot to the latest and not the kernel all while
>> using the U-Boot provided DT and not just loading the matching kernel
>> DT supplied by what ever ancient kernel they happen to choose to use?

Everyone who wants to boot the UEFI/distro way, using the DT as a
hardware description, provided by the firmware. Yes, for years people
got used to somehow get some matching revision of the right DT loaded
together with the kernel, but the UEFI boot flow makes this rather hard
to do.
And with the availability of $fdtcontroladdr (which is actually
implicit if bootefi is just called with one argument) this would all fit
so nicely: You have your device specific firmware build (firmware in the
classis sense, not the Android meaning), and the rest (kernel, userland,
secondary bootloaders) is generic and everything falls in place.

>> I feel this use case is quite a corner case and in those cases they're
>> probably not using a vanilla upstream U-Boot anyway.
> 
> Sure people using an old Linux distribution not providing an U-Boot
> image may do so.
> 
> But here we are talking about the U-Boot device tree.

What is a "U-Boot device tree"? The device tree describes the hardware,
so how would that be different between Linux, U-Boot, FreeBSD or Zephyr?
For practical reasons (no on-board storage, for instance) the DT is
shipped with some software/firmware, but the concept is still that of a
kernel-agnostic description.

Actually U-Boot's own DT needs are very minimal: we could get away with
a VERY basic DT, barely containing a clock node, and MMC, EMAC and USB
nodes with just reg and clocks properties.

But since a U-Boot build is per-board, it sounds natural to make this
the only place which holds the respective devicetree, so any user would
just consume it and doesn't need to have any further board specific
information.

> As Linux device
> trees are release specific you should not try to boot Linux using a
> devicetree not provided by the exact same Linux version.

Where does this statement come from? Definitely you can boot Linux with
DTs from a previous version, but conceptually DTs are independent from
any software consumer. It's just very hard to get that right if you
don't have all the documentation upfront, to create DT nodes which
describe everything you need. That's why some platform maintainers
decided to not guarantee forward compatibility for their platform.
Which doesn't mean we should not still aim at this, hence my request to
tweak some compatible string to restore compatibility across various
Linux kernel releases (used by distributions as their official kernel).

> So incompatiblities between old Linux releases and U-Boot's device tree
> should be irrelevant.
> 
> Best regards
> 
> Heinrich
> 
>>
>>> I was experimenting with some small changes (compared to mainline) to
>>> overcome those issues, mostly by *adding* compatible strings instead of
>>> *replacing* them.
>>
>> Shouldn't they be added to a -u-boot.dtsi?

This might be a possible way to implement this, although the idea of
those files is to accommodate U-Boot specific nodes or properties.

Cheers,
Andre

>>> So I would like to ask for a few days so that I can do more testing with
>>> various kernels. I would then post those changes, so that we can discuss
>>> them.
>>>
>>> Cheers,
>>> Andre
>>>
>>>>
>>>> Signed-off-by: Peter Robinson 
>>>> ---
>>>>  arch/arm/dts/sun50i-a64.dtsi | 532 ---
>>>>  1 file changed, 434 insertions(+), 98 deletions(-)
>>>>

Re: [PATCH 8/8] Initial Pine64 Pinephone support

[André Przywara]

On 27/07/2020 14:49, Peter Robinson wrote:

Hi,

thanks for piecing this together. As Maxime mentioned, many options are
not necessary (see below).

Some options are now set by ARCH_SUNXI, since 48313fe51008.

>> On Wed, Jul 22, 2020 at 03:18:40PM +0100, Peter Robinson wrote:
>>> The Pine64 Pinephone is a smartphone based on the AllWinner A64 SoC.
>>> It has the following features:
>>> * 2GB LPDDR3 SDRAM
>>> * 5.95 inch 1440x720 HD IPS capacitive touchscreen
>>> * 16GB eMMC, mSD slot
>>> * Quectel EG25 LTE Modem
>>> * Realtek RTL8723CS WiFi/BT
>>> * Front and read cameras
>>> * Accelerometer, gyro, proximity, ambient light, compass sensors
>>> * A USB Type-C, USB Host, DisplayPort alt mode output, 15W 5V 3A Quick 
>>> Charge, follows USB PD specification
>>>
>>> Signed-off-by: Peter Robinson 
>>> ---
>>>  arch/arm/Kconfig|  2 +-
>>>  configs/pinephone_defconfig | 38 +
>>>  2 files changed, 39 insertions(+), 1 deletion(-)
>>>  create mode 100644 configs/pinephone_defconfig
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index e16fe03887..636ba26938 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -1004,7 +1004,7 @@ config ARCH_SUNXI
>>>   bool "Support sunxi (Allwinner) SoCs"
>>>   select BINMAN
>>>   select CMD_GPIO
>>> - select CMD_MMC if MMC
>>> +select CMD_MMC if MMC
>>
>> That looks like a typo?
> 
> Yes, it is.
> 
>>>   select CMD_USB if DISTRO_DEFAULTS
>>>   select CLK
>>>   select DM
>>> diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
>>> new file mode 100644
>>> index 00..d5750aa954
>>> --- /dev/null
>>> +++ b/configs/pinephone_defconfig
>>> @@ -0,0 +1,38 @@
>>> +CONFIG_ARM=y
>>> +CONFIG_ARCH_SUNXI=y
>>> +CONFIG_SPL=y
>>> +CONFIG_MACH_SUN50I=y
>>> +CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>> +CONFIG_DRAM_CLK=552
>>> +CONFIG_DRAM_ZQ=3881949
>>> +CONFIG_NR_DRAM_BANKS=1

defaults to 1 now for ARCH_SUNXI

>>> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>> +CONFIG_R_I2C_ENABLE=y
>>> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>> +# CONFIG_SPL_SPI_SUNXI is not set

defaults to n

>>> +# CONFIG_SPL_DOS_PARTITION is not set
>>> +# CONFIG_SPL_EFI_PARTITION is not set

those two default to "n" now for ARCH_SUNXI

>>> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.1"
>>> +CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.0"
>>> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y

defaults to y now for ARCH_SUNXI

>>> +CONFIG_DM_REGULATOR=y
>>> +CONFIG_DM_REGULATOR_FIXED=y
>>> +CONFIG_DM_PWM=y
>>> +CONFIG_PWM_SUNXI=y
>>> +CONFIG_CMD_GPIO=y
>>> +CONFIG_CMD_GPT=y

those two are already y be default

>>> +CONFIG_CMD_I2C=y
>>> +CONFIG_CMD_MMC=y

already y by default

>>> +# CONFIG_CMD_MII is not set
>>> +# CONFIG_CMD_NFS is not set
>>> +# CONFIG_DM_ETH is not set
>>> +# CONFIG_PHY is not set
>>> +# CONFIG_PHY_GIGE is not set
>>> +# CONFIG_SUN8I_EMAC is not set
>>> +# CONFIG_PHY_REALTEK is not set
>>> +# CONFIG_CMD_SF is not set
>>> +# CONFIG_SPI is not set
>>> +# CONFIG_DM_SPI is not set

Those two sounds like a good idea, but don't do anything, because
ARCH_SUNXI selects them. Sounds weird, and looks like not the right
thing, tbh.

>>> +# CONFIG_SPI_FLASH is not set
>>> +# CONFIG_SPI_MEM is not set
>>> +# CONFIG_DM_SPI_FLASH is not set
>>
>> I'm not entirely sure why we need to deviate from the default that much
>> here. Some options should definitely be disabled (like SUN8I_EMAC), but
>> I'm not really sure why it's enabled in the first place, and why we need
> 
> Because it's selected by default for the SoC,

Mmmh, really? I don't see that in Kconfig, and in fact removing that
"#CONFIG_SUN8I_EMAC is not set" line results in the exact same .config
created.

> I suspect that's because
> it was assumed that everything would be a dev board and have a wired
> ethernet port but there's more and more devices that don't so it
> probably makes sense to review that but I didn't want to do that as
> part of enabling a device.

Explicitly un-setting just CONFIG_NET should disable all network related
options. This disables even more commands and features than your
version, which is fine, unless we want USB Ethernet support. Doesn't
seem to be enabled with your config, and I don't know what's the USB
story on the Pinephone in general, and in U-Boot in particular.
What are the expectations in this regard?

Cheers,
Andre

>> to disable the other network related options (PHY, PHY_GIGE,
>> PHY_REALTEK). They shouldn't even be enabled in the first place.
> 
> That would be my guess but I suspect it's the same as the SUN8I_EMAC above.
> 
>> Similarly, CMD_GPIO, CMD_GPT should be enabled by default.
>>
>> (and I'm not sure why PWM_SUNXI is here in the first place?)
> 
> It's used by the backlight, it shouldn't have made it into this patch,
> as the DT bits aren't upstream yet and as I mentioned in my overview
> the screen side of things is still a WiP, I must have missed it as I
> sliced up my patch set between 

Re: [PATCH 6/8] arm: dts: Sync the sun50i-a64.dtsi from Linux 5.8-rc1

[André Przywara]

On 22/07/2020 15:18, Peter Robinson wrote:
> Sync the Allwinner A64 sun50i-a64.dtsi from Linux.

Hi Peter,

thanks for your series!

While this looks mostly straight-forward, the problem is that this patch
here affects all Allwinner boards. And for them it breaks older kernels,
which cannot cope with some of the changed bindings or nodes.
Your patches up until here are fine, since they only add nodes and
properties, but this update changes nodes, some in a non-compatible way.

Examples are dropping the "syscon" compatible (which requires 4.18 to
know about the new compatible string) and the dropping of
internal-osc-clk and the connected RTC change. This breaks any kernels
that don't know about the third RTC clock (< 2>) or the new
compatible string (introduced in 4.20). Similar effects show up in other
OSes.

I was experimenting with some small changes (compared to mainline) to
overcome those issues, mostly by *adding* compatible strings instead of
*replacing* them.

So I would like to ask for a few days so that I can do more testing with
various kernels. I would then post those changes, so that we can discuss
them.

Cheers,
Andre

> 
> Signed-off-by: Peter Robinson 
> ---
>  arch/arm/dts/sun50i-a64.dtsi | 532 ---
>  1 file changed, 434 insertions(+), 98 deletions(-)
> 
> diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
> index ff41abc96a..8dfbcd1440 100644
> --- a/arch/arm/dts/sun50i-a64.dtsi
> +++ b/arch/arm/dts/sun50i-a64.dtsi
> @@ -1,46 +1,7 @@
> -/*
> - * Copyright (C) 2016 ARM Ltd.
> - * based on the Allwinner H3 dtsi:
> - *Copyright (C) 2015 Jens Kuske 
> - *
> - * This file is dual-licensed: you can use it either under the terms
> - * of the GPL or the X11 license, at your option. Note that this dual
> - * licensing only applies to this file, and not this project as a
> - * whole.
> - *
> - *  a) This file is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of the
> - * License, or (at your option) any later version.
> - *
> - * This file is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * Or, alternatively,
> - *
> - *  b) Permission is hereby granted, free of charge, to any person
> - * obtaining a copy of this software and associated documentation
> - * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use,
> - * copy, modify, merge, publish, distribute, sublicense, and/or
> - * sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following
> - * conditions:
> - *
> - * The above copyright notice and this permission notice shall be
> - * included in all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
> - */
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2016 ARM Ltd.
> +// based on the Allwinner H3 dtsi:
> +//Copyright (C) 2015 Jens Kuske 
>  
>  #include 
>  #include 
> @@ -49,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  / {
>   interrupt-parent = <>;
> @@ -84,35 +46,47 @@
>   #size-cells = <0>;
>  
>   cpu0: cpu@0 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> + compatible = "arm,cortex-a53";
>   device_type = "cpu";
>   reg = <0>;
>   enable-method = "psci";
>   next-level-cache = <>;
> + clocks = < 21>;
> + clock-names = "cpu";
> + #cooling-cells = <2>;
>   };
>  
>   cpu1: cpu@1 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> + compatible = "arm,cortex-a53";
>   device_type = "cpu";
>   reg = <1>;
>   enable-method = "psci";
>   next-level-cache = <>;
> + clocks = < 21>;
> + clock-names = "cpu";
> + #cooling-cells = 

Re: [PATCH 14/15] net: sun8i-emac: Lower MDIO frequency

[André Przywara]

On 11/07/2020 10:27, Jagan Teki wrote:

Hi,

> On Mon, Jul 6, 2020 at 6:12 AM Andre Przywara  wrote:
>>
>> When sending a command via the MDIO bus, the Designware MAC expects some
>> bits in the CMD register to describe the clock divider value between
>> the main clock and the MDIO clock.
>> So far we were omitting these bits, resulting in setting "00", which
>> means "/ 16", so ending up with an MDIO frequency of either 18.75 or
>> 12.5 MHz.
>> All the internal PHYs in the H3/H5/H6 SoCs as well as the Gbit Realtek
>> PHYs seem to be fine with that - although it looks like to be severly
>> overclocked (the MDIO spec limits the frequency to 2.5 MHz).
>> However the external 100Mbit PHY on the Pine64 (non-plus) board is
>> not happy with that, Ethernet was actually never working there, as the
>> PHY didn't probe.
> 
> How come the existing divider cannot work with 100Mbit external
> PHY(assuming external regulator pin as properly enabled) since it
> works with 1Gbit already?

Because it's far too high to be MDIO spec compliant. My guess is that
some PHYs (for instance the RTL8211 used on most boards with GBit
Ethernet) can cope with that, but apparently that's too much for the
RTL8201 on the Pine64. I would say that most boards have either an
external GBit PHY or use the internal PHY for 100MBit, so there are not
many boards using the sun8i EMAC with an 8201 PHY, that's why nobody
complained so far.

At least this is my best guess, based on the observation that this patch
makes the difference between Ethernet working or not on the Pine64
(non-plus).

Cheers,
Andre.

Re: [PATCH v3 5/5] arm: qemu: override flash accessors to use virtualizable instructions

[André Przywara]

On 07/07/2020 11:07, Ard Biesheuvel wrote:
> Some instructions in the ARM ISA have multiple output registers, such
> as ldrd/ldp (load pair), where two registers are loaded from memory,
> but also ldr with indexing, where the memory base register is incremented
> as well when the value is loaded to the destination register.
> 
> MMIO emulation under KVM is based on using the architecturally defined
> syndrome information that is provided when an exception is taken to the
> hypervisor. This syndrome information describes whether the instruction
> that triggered the exception is a load or a store, what the faulting
> address was, and which register was the destination register.
> 
> This syndrome information can only describe one destination register, and
> when the trapping instruction is one with multiple outputs, KVM throws an
> error like
> 
>   kvm [615929]: Data abort outside memslots with no valid syndrome info
> 
> on the host and kills the QEMU process with the following error:
> 
>   U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)
> 
>   DRAM:  1 GiB
>   Flash: error: kvm run failed Function not implemented
>   R00=0001 R01=0040 R02=7ee0ce20 R03=
>   R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
>   R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
>   R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
>   PSR=21d3 --C- A svc32
>   QEMU: Terminated
> 
> This means that, in order to run U-Boot in QEMU under KVM, we need to
> avoid such instructions when accessing emulated devices. For the flash
> in particular, which is a hybrid between a ROM (backed by a read-only
> KVM memslot) when in array mode, and an emulated MMIO device (when in
> write mode), we need to take care to only use instructions that KVM can
> deal with when they trap.
> 
> So override the flash read accessors that are used when running on QEMU
> under KVM. Note that the the 64-bit wide read and write accessors have
> been omitted: they are never used when running under QEMU given that it
> does not emulate CFI flash that supports it.

Yes, that issue causes quite some headaches. In the Linux kernel the
MMIO accessors were deliberately chosen to be the ldr/str instructions
(as in this patch), to avoid this issue in the first place. So MMIO from
a Linux guest always works.
So it only makes sense to follow suit there. On the next occasion we
could actually think about moving the standard accessors over as well,
but for now this is good enough.

> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/emulation/qemu-arm/qemu-arm.c | 45 
>  include/configs/qemu-arm.h  |  1 +
>  2 files changed, 46 insertions(+)
> 
> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> b/board/emulation/qemu-arm/qemu-arm.c
> index 1b0d543b93c1..f18f2ed7da3a 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -142,3 +142,48 @@ efi_status_t platform_get_rng_device(struct udevice 
> **dev)
>   return EFI_SUCCESS;
>  }
>  #endif /* CONFIG_EFI_RNG_PROTOCOL */
> +
> +#ifdef CONFIG_ARM64
> +#define __W  "w"
> +#else
> +#define __W
> +#endif
> +
> +u8 flash_read8(void *addr)
> +{
> + u8 ret;
> +
> + asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
> + return ret;
> +}
> +
> +u16 flash_read16(void *addr)
> +{
> + u16 ret;
> +
> + asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
> + return ret;
> +}
> +
> +u32 flash_read32(void *addr)
> +{
> + u32 ret;
> +
> + asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
> + return ret;
> +}
> +
> +void flash_write8(u8 value, void *addr)
> +{
> + asm("strb %" __W "1, %0" : "=m"(*(u8 *)addr) : "r"(value));
> +}
> +
> +void flash_write16(u16 value, void *addr)
> +{
> + asm("strh %" __W "1, %0" : "=m"(*(u16 *)addr) : "r"(value));
> +}
> +
> +void flash_write32(u32 value, void *addr)
> +{
> + asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value));
> +}
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index 1ef75a87836b..bc8b7c5c1238 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -53,5 +53,6 @@
>  #define CONFIG_SYS_MAX_FLASH_BANKS   2
>  #endif
>  #define CONFIG_SYS_MAX_FLASH_SECT256 /* Sector: 256K, Bank: 64M */
> +#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
>  
>  #endif /* __CONFIG_H */
> 

Re: [PATCH v3 3/5] arm: qemu: implement enable_caches()

[André Przywara]

On 07/07/2020 11:07, Ard Biesheuvel wrote:
> Add an override for enable_caches to enable the I and D caches, along
> with the cached 1:1 mapping of all of DRAM. This is needed for running
> U-Boot under virtualization with QEMU/kvm.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  board/emulation/qemu-arm/qemu-arm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> b/board/emulation/qemu-arm/qemu-arm.c
> index 69e8ef46f1f5..1b0d543b93c1 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
>   return (void *)CONFIG_SYS_SDRAM_BASE;
>  }
>  
> +void enable_caches(void)
> +{
> +  icache_enable();
> +  dcache_enable();

It looks like there is a stray space after the tab, but regardless:

Reviewed-by: Andre Przywara 

Cheers,
Andre

> +}
> +
>  #if defined(CONFIG_EFI_RNG_PROTOCOL)
>  #include 
>  #include 
> 

Re: [PATCH v3 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH

[André Przywara]

On 07/07/2020 11:07, Ard Biesheuvel wrote:
> The LPAE versions of DCACHE_WRITEBACK and DCACHE_WRITETHROUGH are currently
> defined as no-allocate for both reads and writes, which deviates from the
> non-LPAE definition, and mostly defeats the purpose of enabling the caches
> in the first place.
> 
> So align LPAE with !LPAE, and enable allocate-on-read for both. And while
> at it, add some clarification about the meaning of the chosen values.

Many thanks for adding those comments!

> Signed-off-by: Ard Biesheuvel 

Verified the bits against the ARMv7 ARM.

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  arch/arm/include/asm/system.h | 23 
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 7a40b56acdca..3a1501a0623c 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -442,10 +442,16 @@ static inline void set_dacr(unsigned int val)
>  #define TTBCR_EPD0   (0 << 7)
>  
>  /*
> - * Memory types
> + * VMSAv8-32 Long-descriptor format memory region attributes
> + * (ARM Architecture Reference Manual section G5.7.4 [DDI0487E.a])
> + *
> + * MAIR0[ 7: 0] 0x00 Device-nGnRnE (aka Strongly-Ordered)
> + * MAIR0[15: 8] 0xaa Outer/Inner Write-Through, Read-Allocate No 
> Write-Allocate
> + * MAIR0[23:16] 0xee Outer/Inner Write-Back, Read-Allocate No Write-Allocate
> + * MAIR0[31:24] 0xff Outer/Inner Write-Back, Read-Allocate Write-Allocate
>   */
> -#define MEMORY_ATTRIBUTES((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
> -  (0xcc << (2 * 8)) | (0xff << (3 * 8)))
> +#define MEMORY_ATTRIBUTES((0x00 << (0 * 8)) | (0xaa << (1 * 8)) | \
> +  (0xee << (2 * 8)) | (0xff << (3 * 8)))
>  
>  /* options available for data cache on each page */
>  enum dcache_option {
> @@ -468,7 +474,16 @@ enum dcache_option {
>  #define TTB_SECT_B_MASK  (1 << 2)
>  #define TTB_SECT (2 << 0)
>  
> -/* options available for data cache on each page */
> +/*
> + * Short-descriptor format memory region attributes, without TEX remap
> + * (ARM Architecture Reference Manual section G5.7.2 [DDI0487E.a])
> + *
> + * TEX[0] C  B
> + *   00  0   Device-nGnRnE (aka Strongly-Ordered)
> + *   01  0   Outer/Inner Write-Through, Read-Allocate No Write-Allocate
> + *   01  1   Outer/Inner Write-Back, Read-Allocate No Write-Allocate
> + *   11  1   Outer/Inner Write-Back, Read-Allocate Write-Allocate
> + */
>  enum dcache_option {
>   DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
>   DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
> 

Re: [PATCH v2] arm64: issue ISB after updating system registers

[André Przywara]

On 24/06/2020 02:05, Volodymyr Babchuk wrote:

Hi Volodymyr,

thanks for the find and for taking care! And thanks Julien for forwarding!

> ARM Architecture reference manual clearly states that PE pipeline
> should be flushed after any change to system registers.

Don't want to be pedantic here, but this does not affect all system
registers. Some clearly don't need an ISB, some are self-synchronising.
The manual speaks of "*Examples* of context-changing operations ..."
Could you change this to "... after changes to some system registers."?

> Refer to
> paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
> Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI
> 0487B.a).
> 
> Failing to issue instruction memory synchronization barrier can lead

It's just "instruction synchronization barrier". This is not really
about memory, it's about making sure that the processor re-fetches the
next instructions and "re-evaluates" them again, to take the changed
system state into account. (Flushing the pipeline is just one possible
way to implement this, btw.)

> to spurious errors, like synchronous exception when accessing FPU
> registers. This is very prominent on CPUs with long instruction
> pipeline, like ARM Cortex A72.
> 
> This change fixes the following U-Boot panic:
> 
>  "Synchronous Abort" handler, esr 0x1fe0
>  elr: 800948cc lr : 80091e04
>  x0 : 801ffdc8 x1 : 00c8
>  x2 : 800979d4 x3 : 801ffc60
>  x4 : 801ffd40 x5 : ff80ffd8
>  x6 : 801ffd70 x7 : 801ffd70
>  x8 : 000a x9 : 
>  x10: 0044 x11: 
>  x12:  x13: 
>  x14:  x15: 
>  x16: 8008b2e0 x17: 
>  x18: 801ffec0 x19: 800957b0
>  x20: 00c8 x21: 801ffdc8
>  x22: 8009909e x23: 
>  x24:  x25: 
>  x26:  x27: 
>  x28:  x29: 801ffc50
> 
>  Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0)
> 
> While executing instruction
> 
>  str q0, [sp, #112]
> 
> in vsnprintf() prologue. This panic was observed only on Cortex A72 so
> far.
> 
> This patch places ISBs on other strategic places as well.
> 
> Also, this probably is the right fix for the issue workarounded in the
> commit 45f41c13 ("ARM: uniphier: add weird workaround code for LD20")
> 
> Reported-by: Oleksandr Andrushchenko 
> Suggested-by: Julien Grall 
> Signed-off-by: Volodymyr Babchuk 
> CC: Tom Rini 
> CC: Masahiro Yamada 
> CC: Stefano Stabellini 

I checked the A57 ACTLR_EL1 and ECTLR_EL1 bits affected below, and
indeed an ISB seems to be in order here. Since this is the
initialization code path, it wouldn't hurt anyway ;-)

Reviewed-by: Andre Przywara 

Cheers,
Andre

> --
> 
> Changes from v1:
>  - Added ISBs under CONFIG_ARMV8_SET_SMPEN and erratas.
>  - Added Stefano, Julien and Oleksandr
> ---
>  arch/arm/cpu/armv8/start.S | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 99d126660d..002698b501 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -120,6 +120,7 @@ pie_fixup_done:
>   mov x0, #3 << 20
>   msr cpacr_el1, x0   /* Enable FP/SIMD */
>  0:
> + isb
>  
>   /*
>* Enable SMPEN bit for coherency.
> @@ -132,6 +133,7 @@ pie_fixup_done:
>   mrs x0, S3_1_c15_c2_1   /* cpuectlr_el1 */
>   orr x0, x0, #0x40
>   msr S3_1_c15_c2_1, x0
> + isb
>  1:
>  #endif
>  
> @@ -233,6 +235,7 @@ apply_a53_core_errata:
>   /* Enable data cache clean as data cache clean/invalidate */
>   orr x0, x0, #1 << 44
>   msr S3_1_c15_c2_0, x0   /* cpuactlr_el1 */
> + isb
>  #endif
>   b 0b
>  
> @@ -247,6 +250,7 @@ apply_a57_core_errata:
>   /* Disable write streaming no-allocate threshold */
>   orr x0, x0, #3 << 27
>   msr S3_1_c15_c2_0, x0   /* cpuactlr_el1 */
> + isb
>  #endif
>  
>  #ifdef CONFIG_ARM_ERRATA_826974
> @@ -254,6 +258,7 @@ apply_a57_core_errata:
>   /* Disable speculative load execution ahead of a DMB */
>   orr x0, x0, #1 << 59
>   msr S3_1_c15_c2_0, x0   /* cpuactlr_el1 */
> + isb
>  #endif
>  
>  #ifdef CONFIG_ARM_ERRATA_833471
> @@ -263,6 +268,7 @@ apply_a57_core_errata:
>   could impact performance. */
>   orr x0, x0, #1 << 38
>   msr S3_1_c15_c2_0, x0   /* cpuactlr_el1 */
> + isb
>  #endif
>  
>  #ifdef CONFIG_ARM_ERRATA_829520
> @@ -273,6 +279,7 @@ apply_a57_core_errata:
>   could impact performance. */
>   orr x0, x0, #1 << 4
>   msr S3_1_c15_c2_0, x0   /* cpuactlr_el1 */
> + isb
>  #endif
>  
>  #ifdef CONFIG_ARM_ERRATA_833069
> @@ -280,6 +287,7 @@ 

Re: [linux-sunxi] Re: [RFC PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40

[André Przywara]

On 24/06/2020 01:34, Icenowy Zheng wrote:

Hi,

> 于 2020年6月24日 GMT+08:00 上午8:28:39, "André Przywara"  
> 写到:
>> On 19/06/2020 13:16, Icenowy Zheng wrote:
>>
>> Hi Icenowy,
>>
>>> Previously we have known that R40 has a configuration register for
>> its
>>> rank 1, which allows different configuration than rank 0. Reverse
>>> engineering of newest libdram of A64 from Allwinner shows that A64
>> has
>>> this register too. It's bit 0 (which enables dual rank in rank 0
>>> configuration register) means a dedicated rank size setup is used for
>>> rank 1.
>>
>> Ah! That's a nice discovery, as it probably explains how my Eachlink H6
>> TV box works with its asymmetric 3GB DRAM config!
> 
> Wait. The configuration of H6 DRAM controller is totally different. it uses
> ADDRMAP registers in DRAM controller, instead of specifying parameters
> in MCTL_COM part.

I see, but at least it confirms that configuring the two ranks
differently is possible. I was always scratching my head how the box
works with two different set of chips (four 4GBit chips and four 2Gbit
chips). Do we support this asymmetric setup for the H6 controller
already, possibly due to the different way of setting this up?
If not I can check out if boot0 does some magic there.

Cheers,
Andre


> 
>>
>>> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
>>> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
>>> DRAM support necessary.
>>>
>>> Add this support. As we have gained knowledge of asymmetric dual
>> rank,
>>> we can now allow R40 dual rank memory setup to work too.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Testing on R40 boards and A64 single rank boards (e.g. the original
>> Pine
>>> A64+) is welcomed. I have these boards, but I get too lazy to take
>> them
>>> out and test them.
>>
>> I briefly tested this on a Bananapi M2 Berry (R40, 1GB), Pine64 512MB
>> and Pine64+ 2GB. All three boot happily into U-Boot, tested the Pine64+
>> to the Linux prompt as well.
>>
>> I will do a proper review shortly.
>>
>> Thanks for the patch!
>>
>> Cheers,
>> Andre
>>
>>>
>>>  .../include/asm/arch-sunxi/dram_sunxi_dw.h|  11 +-
>>>  arch/arm/mach-sunxi/dram_sunxi_dw.c   | 100
>> +-
>>>  2 files changed, 84 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> index a5a7ebde44..e843c14202 100644
>>> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>>>  #define NR_OF_BYTE_LANES   (32 / BITS_PER_BYTE)
>>>  /* The eight data lines (DQn) plus DM, DQS and DQSN */
>>>  #define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3)
>>> -struct dram_para {
>>> +
>>> +struct rank_para {
>>> u16 page_size;
>>> -   u8 bus_full_width;
>>> -   u8 dual_rank;
>>> u8 row_bits;
>>> u8 bank_bits;
>>> +};
>>> +
>>> +struct dram_para {
>>> +   u8 dual_rank;
>>> +   u8 bus_full_width;
>>> +   struct rank_para ranks[2];
>>> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>>> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>>> const u8 ac_delays[31];
>>> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> index a462538521..7a40d92349 100644
>>> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> @@ -349,18 +349,24 @@ static void mctl_set_cr(uint16_t socid, struct
>> dram_para *para)
>>>  #else
>>>  #error Unsupported DRAM type!
>>>  #endif
>>> -  (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>>> +  (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>>>MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>>>(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK)
>> |
>>> -  MCTL_CR_PAGE_SIZE(para->page_size) |
>>> -  MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
>>> +  MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
>>> +  MCTL_CR_ROW_B

Re: [RFC PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40

[André Przywara]

On 19/06/2020 13:16, Icenowy Zheng wrote:

Hi Icenowy,

> Previously we have known that R40 has a configuration register for its
> rank 1, which allows different configuration than rank 0. Reverse
> engineering of newest libdram of A64 from Allwinner shows that A64 has
> this register too. It's bit 0 (which enables dual rank in rank 0
> configuration register) means a dedicated rank size setup is used for
> rank 1.

Ah! That's a nice discovery, as it probably explains how my Eachlink H6
TV box works with its asymmetric 3GB DRAM config!

> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
> DRAM support necessary.
> 
> Add this support. As we have gained knowledge of asymmetric dual rank,
> we can now allow R40 dual rank memory setup to work too.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Testing on R40 boards and A64 single rank boards (e.g. the original Pine
> A64+) is welcomed. I have these boards, but I get too lazy to take them
> out and test them.

I briefly tested this on a Bananapi M2 Berry (R40, 1GB), Pine64 512MB
and Pine64+ 2GB. All three boot happily into U-Boot, tested the Pine64+
to the Linux prompt as well.

I will do a proper review shortly.

Thanks for the patch!

Cheers,
Andre

> 
>  .../include/asm/arch-sunxi/dram_sunxi_dw.h|  11 +-
>  arch/arm/mach-sunxi/dram_sunxi_dw.c   | 100 +-
>  2 files changed, 84 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index a5a7ebde44..e843c14202 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>  #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
>  /* The eight data lines (DQn) plus DM, DQS and DQSN */
>  #define LINES_PER_BYTE_LANE  (BITS_PER_BYTE + 3)
> -struct dram_para {
> +
> +struct rank_para {
>   u16 page_size;
> - u8 bus_full_width;
> - u8 dual_rank;
>   u8 row_bits;
>   u8 bank_bits;
> +};
> +
> +struct dram_para {
> + u8 dual_rank;
> + u8 bus_full_width;
> + struct rank_para ranks[2];
>   const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>   const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>   const u8 ac_delays[31];
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index a462538521..7a40d92349 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -349,18 +349,24 @@ static void mctl_set_cr(uint16_t socid, struct 
> dram_para *para)
>  #else
>  #error Unsupported DRAM type!
>  #endif
> -(para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +(para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
>  MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>  (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> -MCTL_CR_PAGE_SIZE(para->page_size) |
> -MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
> +MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>  
> - if (socid == SOCID_R40) {
> - if (para->dual_rank)
> - panic("Dual rank memory not supported\n");
> + if (socid == SOCID_A64 || socid == SOCID_R40) {
> + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> +(para->dual_rank ? MCTL_CR_DUAL_RANK : 
> MCTL_CR_SINGLE_RANK) |
> +MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[1].row_bits), 
> _com->cr_r1);
> + }
>  
> + if (socid == SOCID_R40) {
>   /* Mux pin to A15 address line for single rank memory. */
> - setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> + if (!para->dual_rank)
> + setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
>   }
>  }
>  
> @@ -584,35 +590,63 @@ static int mctl_channel_init(uint16_t socid, struct 
> dram_para *para)
>   return 0;
>  }
>  
> -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para 
> *para)
> +/*
> + * Test if memory at offset offset matches memory at a certain base
> + */
> +static bool mctl_mem_matches_base(u32 offset, ulong base)
> +{
> + /* Try to write different values to RAM at two addresses */
> + writel(0, base);
> + writel(0xaa55aa55, base + offset);
> + dsb();
> + /* Check if the same value is actually observed when reading back */
> + return readl(base) ==
> +readl(base + offset);
> +}
> +
> +static void mctl_auto_detect_dram_size_rank(uint16_t 

Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd

[André Przywara]

On 09/06/2020 19:47, Michael Nazzareno Trimarchi wrote:

Hi,

that looks much better now, thanks! Some suggestion below.

> On Tue, Jun 9, 2020 at 6:13 AM Bin Meng  wrote:
>>
>> Hi André,
>>
>> On Mon, Jun 8, 2020 at 9:52 PM André Przywara  wrote:
>>>
>>> On 07/06/2020 12:22, Jagan Teki wrote:
>>>
>>> Hi,
>>>
>>> (CC: ing Mark)
>>>
>>> Without looking to deep, I think invalidating the cache might be the
>>> right thing to do, but the rationale or at least the wording of it seems
>>> somehow flawed:
>>>
>>>> Some architecture like ARM Cortex A53, A72 would need
>>>
>>> Please don't mix the term "architecture" with actual implementations.
>>> And the problem is more general, I would say. This *might* be a case
>>> here where this is due to speculation, and then I would expect it to
>>> only show on an A72, for instance. I guess this is about NVMe on RK3399?
>>> Does U-Boot run on an A53 or an A72 core?
>>>
>>>> to invalidate dcache to sync the cache with the memory
>>>> contents before flushing the cache to memory.
>>>
>>> That is somewhat confusing. What does "sync" and "flush" mean here?
>>> AFAIK only "clean" and "invalidate" are clearly defined terms.
>>> The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is
>>> purely about the buffer for the *return* data, in which case I would
>>> expect this being a pure invalidation problem.
>>>
>>> This issue looks like the case described on slide 30 and 31 here:
>>> https://elinux.org/images/6/6d/Rutland2.pdf
>>
>> Thanks for the slides. This is really helpful.
>>
>>>
>>>> The NVME here submitting the admin command using dma_addr
>>>> to the memory without prior cache invalidation. This causing
>>>> dma_addr is pointing to an invalid location in the memory
>>>
>>> This does not sound right: dma_addr is always pointing to the right
>>> location in memory.
>>> The actual reason this fixes something might be that (some) cache lines
>>> of the DMA buffer were dirty and were evicted *before* the existing
>>> invalidation, but *after* the DMA transfer. That sounds unlikely in an
>>> U-Boot context, though, but would match the case described in Mark's slides.
>>>
>>> So there might be more to this. Are we missing a barrier here? Should we
>>> use coherent buffers (memory mapped as un-cached) for the return DMA in
>>> the first place (but I don't think U-Boot provides those)?
>>>
>>>> and found the sane nvme_ctrl result.
>>>>
>>>> Below example shows the nvme disk scan result improper result
>>>>
>>>> => nvme scan
>>>> nvme_get_info_from_identify: nn = 544502629, vwc = 100,
>>>> sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105
>>>>
>>>> So, invalidating the cache before submitting the admin command
>>>> makes the dma_addr points to a valid location in the memory.
>>>
>>> If this shows up already, I think we should address all the comments in
>>> the driver where it says we should do cache maintenance. And it makes me
>>> wonder how this actually works today ...
>>>
>>
>> I believe the driver was only validated on x86 and NXP's PowerPC
>> series where cache coherence is ensured between the DMA master and the
>> system memory. I suspect it was never validated on ARM hence this
>> patch.
>>
>> I agree we should address all the comments in the driver about cache
>> maintenance.
> 
> What about this description:
> 
> nvme: Invalidate dcache before submitting admin cmd
> 
> This patch tries to avoid eviction of dirty lines during DMA
> transfer. The code right now executes the following step:
> 
> - allocate the buffer
> - start a DMA operation using the non-coherent DMA buffer
> - invalidate cache lines associated with the buffer
> - read the buffer
> 
> This can lead to reading back not valid information. CPU can still read
> stale data. In order to avoid the eviction of dirty lines, a new
> invalidation is required before starting the DMA operation. The patch
> just adds an invalidation before submitting the DMA command.

As I think this case is not obvious, I would make it more clear what
actually happens here, for instance (replace your paragraph above):

==
This can lead to reading back not valid information, because the cache
controller could evict di

Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd

[André Przywara]

On 07/06/2020 12:22, Jagan Teki wrote:

Hi,

(CC: ing Mark)

Without looking to deep, I think invalidating the cache might be the
right thing to do, but the rationale or at least the wording of it seems
somehow flawed:

> Some architecture like ARM Cortex A53, A72 would need

Please don't mix the term "architecture" with actual implementations.
And the problem is more general, I would say. This *might* be a case
here where this is due to speculation, and then I would expect it to
only show on an A72, for instance. I guess this is about NVMe on RK3399?
Does U-Boot run on an A53 or an A72 core?

> to invalidate dcache to sync the cache with the memory
> contents before flushing the cache to memory.

That is somewhat confusing. What does "sync" and "flush" mean here?
AFAIK only "clean" and "invalidate" are clearly defined terms.
The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is
purely about the buffer for the *return* data, in which case I would
expect this being a pure invalidation problem.

This issue looks like the case described on slide 30 and 31 here:
https://elinux.org/images/6/6d/Rutland2.pdf

> The NVME here submitting the admin command using dma_addr
> to the memory without prior cache invalidation. This causing
> dma_addr is pointing to an invalid location in the memory

This does not sound right: dma_addr is always pointing to the right
location in memory.
The actual reason this fixes something might be that (some) cache lines
of the DMA buffer were dirty and were evicted *before* the existing
invalidation, but *after* the DMA transfer. That sounds unlikely in an
U-Boot context, though, but would match the case described in Mark's slides.

So there might be more to this. Are we missing a barrier here? Should we
use coherent buffers (memory mapped as un-cached) for the return DMA in
the first place (but I don't think U-Boot provides those)?

> and found the sane nvme_ctrl result.
> 
> Below example shows the nvme disk scan result improper result
> 
> => nvme scan
> nvme_get_info_from_identify: nn = 544502629, vwc = 100,
> sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105
> 
> So, invalidating the cache before submitting the admin command
> makes the dma_addr points to a valid location in the memory.

If this shows up already, I think we should address all the comments in
the driver where it says we should do cache maintenance. And it makes me
wonder how this actually works today ...

Cheers,
Andre.

> 
> Cc: Andre Przywara  
> Reported-by: Suniel Mahesh 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> Tested-by: Suniel Mahesh 
> ---
>  drivers/nvme/nvme.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 0357aba7f1..fc64d93ab8 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -466,6 +466,9 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
>  
>   c.identify.cns = cpu_to_le32(cns);
>  
> + invalidate_dcache_range(dma_addr,
> + dma_addr + sizeof(struct nvme_id_ctrl));
> +
>   ret = nvme_submit_admin_cmd(dev, , NULL);
>   if (!ret)
>   invalidate_dcache_range(dma_addr,
>