Re: [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update

2022-01-25 Thread AKASHI Takahiro
On Wed, Jan 26, 2022 at 11:29:10AM +0900, Masami Hiramatsu wrote:
> BTW, the original code comes from EDK2 implementation.

What do you mean by "original code"?

> It seems that this INITIATE_RESET flag meaning in EDK2 is a bit different
> from what we thought here.

Yeah,

> The flag is only used for resetting system via
> UpdateCapsule() EFI call. The capsule update process itself will be done
> at the boot time and warm reset soon after that.

EDK2's UpdateCapsule() seems to
- immediately process *all* the capsules with !PERSIST_ACROSS_RESET
- Set "CapsuleUpdateData" variable with a physical address of capsule data
- If some of capsules have INITIATE_RESET, kick in warm restart
After restart,
- process the rest of capsules with PERSIST_ACROSS_RESET
  using "CapsuleUpdateData" (?)

> (See HandleCapsules()@ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c)
> 
> Is it OK to change the INITIATE_RESET flag means? or should we forcibly
> reset the system if we succeeded to update capsule on boot time?
> (note that capsule on disk must be done at boot time in U-Boot)

Obviously, we are trying to use the flag in a different way;
initiating a reset *after* processing a capsule.

While I think that the text in the specification is still ambiguous,
we should not give the flag a different meaning.

In 8.5.5 "Delivery of Capsules via file on Mass Storage device",
In all cases that a capsule is identified for processing the system is
restarted after capsule processing is completed.

So a reset in case of capsule-on-disk seems mandatory.
(Personally, I don't like the system to enforce a reset.)

The discussion above also indicates that the current efi_launch_capsules()
must be reworked so not to use efi_update_capsule() which is to honor
the flags in a capsule header.

-Takahiro Akashi

> Thank you,
> 
> 2022年1月26日(水) 7:31 Masami Hiramatsu :
> >
> > Hi Takahiro,
> >
> > 2022年1月25日(火) 21:49 AKASHI Takahiro :
> > >
> > > Hi Masami,
> > >
> > > Thank you for this enhancement.
> > >
> > > On Tue, Jan 25, 2022 at 08:31:29PM +0900, Masami Hiramatsu wrote:
> > > > Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after
> > > > updating firmware. Note that the machine will reboot soon after
> > > > applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET
> > > > flag. If there are multiple capsules and one has this flag, the
> > > > machine may reboot while scanning the capsule files.
> > > > You can control when the machine reboot by renaming the capsule
> > > > file because the capsule files will be applied alphabetically.
> > > >
> > > > Signed-off-by: Masami Hiramatsu 
> > > > ---
> > > >  lib/efi_loader/efi_capsule.c |   13 +
> > > >  1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > > index 4463ae00fd..24a2a026a9 100644
> > > > --- a/lib/efi_loader/efi_capsule.c
> > > > +++ b/lib/efi_loader/efi_capsule.c
> > > > @@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware(
> > > >   struct efi_firmware_management_protocol *fmp;
> > > >   u16 *abort_reason;
> > > >   efi_status_t ret = EFI_SUCCESS;
> > > > + bool reset = false;
> > > >
> > > >   /* sanity check */
> > > >   if (capsule_data->header_size < sizeof(*capsule) ||
> > > >   capsule_data->header_size >= capsule_data->capsule_image_size)
> > > >   return EFI_INVALID_PARAMETER;
> > > >
> > > > + if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) {
> > > > + /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag 
> > > > */
> > > > + if (!(capsule_data->flags & 
> > > > CAPSULE_FLAGS_PERSIST_ACROSS_RESET))
> > > > + return EFI_INVALID_PARAMETER;
> > > > + reset = true;
> > > > + }
> > > > +
> > > >   capsule = (void *)capsule_data + capsule_data->header_size;
> > > >   capsule_size = capsule_data->capsule_image_size
> > > >   - capsule_data->header_size;
> > > > @@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware(
> > > >  out:
> > > >   efi_free_pool(handles);
> > > >
> > > > + if (ret == EFI_SUCCESS && reset) {
> > > > + log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. 
> > > > Reboot machine.\n");
> > > > + do_reset(NULL, 0, 0, NULL);
> > >
> > > I don't think this is the right place of calling do_reset().
> > > Whenever you have processed any capsule file, you have to
> > >  - delete the capsule file,
> > >  - create/update "Capsule" and "CapsuleLast" variables, and
> > >  - modify ESRT table
> > > before initiating a reset.
> >
> > Oops, indeed. Let me update the patch.
> > Thank you!
> >
> > >
> > > -Takahiro Akashi
> > >
> > > > + }
> > > > +
> > > >   return ret;
> > > >  }
> > > >  #else
> > > >
> >
> >
> >
> > --
> > Masami Hiramatsu
> 
> 
> 
> -- 
> Masami Hiramatsu


Re: [PATCH 05/11] ARM: sunxi: Add support for F1C100s

2022-01-25 Thread Jesse Taube




On 1/25/22 21:05, Andre Przywara wrote:

On Tue,  4 Jan 2022 19:35:02 -0500
Jesse Taube  wrote:

Hi,

can you please change the subject, to maybe mention clocks? Reads
rather generic as is.


From: Icenowy Zheng 

This patch aims to add header files for the F1C100s.
The header files included add support for gpio, dram and clocks.


This looks to be about clocks and UARTs only?



Signed-off-by: Icenowy Zheng 
Signed-off-by: Jesse Taube 
---
  arch/arm/include/asm/arch-sunxi/clock.h   |  2 +-
  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 +++
  arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |  8 ++
  arch/arm/include/asm/arch-sunxi/gpio.h|  1 +
  4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
b/arch/arm/include/asm/arch-sunxi/clock.h
index cbbe5c7a1e..2cfd540742 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -19,7 +19,7 @@
  #elif defined(CONFIG_SUN50I_GEN_H6)
  #include 
  #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
-  defined(CONFIG_MACH_SUN50I)
+  defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUNIV)
  #include 
  #elif defined(CONFIG_MACH_SUN9I)
  #include 
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index ee387127f3..5ecdf58bd5 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -168,6 +168,14 @@ struct sunxi_ccm_reg {
u32 pll_lock_ctrl;  /* 0x320 PLL lock control, R40 only */
  };
  
+/* apb1 bit field */

+#ifdef CONFIG_MACH_SUNIV
+#define APB1_GATE_UART_SHIFT   (20)
+#define APB1_GATE_UART_MASK(0x7 << APB1_GATE_UART_SHIFT)
+#define APB1_GATE_TWI_SHIFT(16)
+#define APB1_GATE_TWI_MASK (0x7 << APB1_GATE_TWI_SHIFT)


The values match the user manual, but I don't see the *_MASK values used
anywhere. Please just drop them.


+#endif
+
  /* apb2 bit field */
  #define APB2_CLK_SRC_LOSC (0x0 << 24)
  #define APB2_CLK_SRC_OSC24M   (0x1 << 24)
@@ -226,7 +234,12 @@ struct sunxi_ccm_reg {
  #define CCM_PLL5_CTRL_SIGMA_DELTA_EN  (0x1 << 24)
  #define CCM_PLL5_CTRL_EN  (0x1 << 31)
  
+#if !defined(CONFIG_MACH_SUNIV)

  #define PLL6_CFG_DEFAULT  0x90041811 /* 600 MHz */
+#else
+/* suniv pll6 doesn't have postdiv 2, so k is set to 0 */
+#define PLL6_CFG_DEFAULT   0x90041800


The manual says that bit 0 resets to 1, as in the other SoCs. It just
seems to affect the "back door clock output", so we should leave it as
1.


Uh I don't understand.


+#endif
  
  #define CCM_PLL6_CTRL_N_SHIFT		8

  #define CCM_PLL6_CTRL_N_MASK  (0x1f << CCM_PLL6_CTRL_N_SHIFT)
@@ -310,6 +323,8 @@ struct sunxi_ccm_reg {
  #define AHB_GATE_OFFSET_USB0  25
  #define AHB_GATE_OFFSET_SATA  24
  #endif
+#define AHB_GATE_OFFSET_SPI1   21
+#define AHB_GATE_OFFSET_SPI0   20


I think this is legacy, we don't need this anymore with the DM clock
driver we use in the SPI driver. The SPL SPI is separate anyway.
Please just drop.


  #define AHB_GATE_OFFSET_MCTL  14
  #define AHB_GATE_OFFSET_GMAC  17
  #define AHB_GATE_OFFSET_NAND0 13
@@ -458,6 +473,8 @@ struct sunxi_ccm_reg {
  #ifdef CONFIG_MACH_SUN8I_R40
  #define AHB_RESET_OFFSET_SATA 24
  #endif
+#define AHB_RESET_OFFSET_SPI1  21
+#define AHB_RESET_OFFSET_SPI0  20


Same here, I don't see that used anywhere.


  #define AHB_RESET_OFFSET_GMAC 17
  #define AHB_RESET_OFFSET_MCTL 14
  #define AHB_RESET_OFFSET_MMC3 11
@@ -488,6 +505,14 @@ struct sunxi_ccm_reg {
  #define AHB_RESET_OFFSET_EPHY 2
  #define AHB_RESET_OFFSET_LVDS 0
  
+/* apb1 reset */

+#ifdef CONFIG_MACH_SUNIV
+#define APB1_RESET_UART_SHIFT  (20)
+#define APB1_RESET_UART_MASK   (0x7 << APB1_RESET_UART_SHIFT)
+#define APB1_RESET_TWI_SHIFT   (16)
+#define APB1_RESET_TWI_MASK(0x7 << APB1_RESET_TWI_SHIFT)
+#endif
+
  /* apb2 reset */
  #define APB2_RESET_UART_SHIFT (16)
  #define APB2_RESET_UART_MASK  (0xff << APB2_RESET_UART_SHIFT)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index d4c795d89c..83178dd5c8 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -122,6 +122,12 @@ defined(CONFIG_MACH_SUN50I)
  
  #define SUNXI_SJTAG_BASE		0x01c23c00
  
+#ifdef CONFIG_MACH_SUNIV

+#define SUNXI_UART0_BASE   0x01c25000
+#define SUNXI_UART1_BASE   0x01c25400
+#define SUNXI_UART2_BASE   0x01c25800
+#endif


That should be moved down and merged into the other chunk below.

Rest looks alright.

Cheers,
Andre



+
  #define SUNXI_TP_BASE 0x01c25000
  #define SUNXI_PMU_BASE0x01c25400
  
@@ -129,9 

Re: [PATCH v3 04/11] drivers: misc: Makefile: Enable fs_loader compilation at SPL Level

2022-01-25 Thread Tom Rini
On Tue, Jan 18, 2022 at 11:12:42AM +0100, Amjad Ouled-Ameur wrote:

> From: Keerthy 
> 
> Enable fs_loader compilation at SPL Level.
> 
> Signed-off-by: Keerthy 
> [Amjad: fix compilation failures for J721e platform]
> Signed-off-by: Amjad Ouled-Ameur 

This causes j7200_evm_r5 and socfpga_arria10 to fail to build now.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] arm: kirkwood: GoFlex Home : Use Marvell uclass mvgbe and PHY driver for Ethernet

2022-01-25 Thread Tony Dinh
The GoFlex Home board has the network chip Marvell 88E1116R.
Use uclass mvgbe and the compatible driver M88E1118R to bring up Ethernet.

- Currently, CONFIG_RESET_PHY_R symbol is used in
arch/arm/mach-kirkwood/include/mach/config.h for all Kirkwood
boards with mv8831116 PHY, with each board defines the function
reset_phy(). Undefine it for this board.
- Add board_eth_init() to use uclass mvgbe to bring up the network.
And remove ad-hoc code.
- Enable CONFIG_PHY_MARVELL to properly configure the network.
- Miscellaneous changes: use CONFIG_SYS_THUMB_BUILD to keep u-boot image
under 512K, use BIT macro, and cleanup comments.

Signed-off-by: Tony Dinh 
---

 board/Seagate/goflexhome/goflexhome.c | 84 ---
 configs/goflexhome_defconfig  |  2 +
 include/configs/goflexhome.h  | 32 +++---
 3 files changed, 22 insertions(+), 96 deletions(-)

diff --git a/board/Seagate/goflexhome/goflexhome.c 
b/board/Seagate/goflexhome/goflexhome.c
index 52be64fb8c..caea89c10e 100644
--- a/board/Seagate/goflexhome/goflexhome.c
+++ b/board/Seagate/goflexhome/goflexhome.c
@@ -1,10 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2021
- * Tony Dinh 
- * Suriyan Ramasami 
- *
- * Copyright (C) 2013 Suriyan Ramasami 
+ * Copyright (C) 2021-2022 Tony Dinh 
+ * Copyright (C) 2013-2021 Suriyan Ramasami 
  *
  * Based on dockstar.c originally written by
  * Copyright (C) 2010  Eric C. Cooper 
@@ -18,14 +15,14 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -98,6 +95,11 @@ int board_early_init_f(void)
return 0;
 }
 
+int board_eth_init(struct bd_info *bis)
+{
+   return cpu_eth_init(bis);
+}
+
 int board_init(void)
 {
/*
@@ -111,73 +113,9 @@ int board_init(void)
return 0;
 }
 
-static int fdt_get_phy_addr(const char *path)
-{
-   const void *fdt = gd->fdt_blob;
-   const u32 *reg;
-   const u32 *val;
-   int node, phandle, addr;
-
-   /* Find the node by its full path */
-   node = fdt_path_offset(fdt, path);
-   if (node >= 0) {
-   /* Look up phy-handle */
-   val = fdt_getprop(fdt, node, "phy-handle", NULL);
-   if (val) {
-   phandle = fdt32_to_cpu(*val);
-   if (!phandle)
-   return -1;
-   /* Follow it to its node */
-   node = fdt_node_offset_by_phandle(fdt, phandle);
-   if (node) {
-   /* Look up reg */
-   reg = fdt_getprop(fdt, node, "reg", NULL);
-   if (reg) {
-   addr = fdt32_to_cpu(*reg);
-   return addr;
-   }
-   }
-   }
-   }
-   return -1;
-}
-
-#ifdef CONFIG_RESET_PHY_R
-/* Configure and enable MV88E1116 PHY */
-void reset_phy(void)
-{
-   u16 reg;
-   int phyaddr;
-   char *name = "ethernet-controller@72000";
-   char *eth0_path = 
"/ocp@f100/ethernet-controller@72000/ethernet0-port@0";
-
-   if (miiphy_set_current_dev(name))
-   return;
-
-   phyaddr = fdt_get_phy_addr(eth0_path);
-   if (phyaddr < 0)
-   return;
-
-   /*
-* Enable RGMII delay on Tx and Rx for CPU port
-* Ref: sec 4.7.2 of chip datasheet
-*/
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
-   miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, );
-   reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
-   miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
-   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
-
-   /* reset the phy */
-   miiphy_reset(name, phyaddr);
-
-   printf("88E1116 Initialized on %s\n", name);
-}
-#endif /* CONFIG_RESET_PHY_R */
-
 #if CONFIG_IS_ENABLED(BOOTSTAGE)
-#define GREEN_LED  (1 << 14)
-#define ORANGE_LED (1 << 15)
+#define GREEN_LED  BIT(14)
+#define ORANGE_LED BIT(15)
 #define BOTH_LEDS  (GREEN_LED | ORANGE_LED)
 #define NEITHER_LED0
 
diff --git a/configs/goflexhome_defconfig b/configs/goflexhome_defconfig
index ec8b7398d0..e6eb00a938 100644
--- a/configs/goflexhome_defconfig
+++ b/configs/goflexhome_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_SKIP_LOWLEVEL_INIT=y
 CONFIG_SYS_DCACHE_OFF=y
 CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_KIRKWOOD=y
 CONFIG_SYS_KWD_CONFIG="board/Seagate/goflexhome/kwbimage.cfg"
 CONFIG_SYS_TEXT_BASE=0x60
@@ -47,6 +48,7 @@ CONFIG_SATA_MV=y
 # CONFIG_MMC is not set
 CONFIG_MTD=y
 CONFIG_MTD_RAW_NAND=y
+CONFIG_PHY_MARVELL=y
 CONFIG_DM_ETH=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
diff --git a/include/configs/goflexhome.h b/include/configs/goflexhome.h
index 90e37d9853..c279579268 100644

Re: [PATCH] scripts: Makefile: also clean subdir dtc

2022-01-25 Thread Simon Glass
On Tue, 25 Jan 2022 at 03:32, Philippe Reynes
 wrote:
>
> Since commit 93b196532254 ("Makefile: Only build dtc if needed"),
> the sub directory scripts/dtc is never cleaned.
> Adds the directory dtc to subdir to always clean it.
>
> Signed-off-by: Philippe Reynes 
> ---
>  scripts/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

I do wish we had a test for cleaning


Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

2022-01-25 Thread Vagrant Cascadian
On 2022-01-25, Vagrant Cascadian wrote:
> On 2022-01-15, Aurelien Jarno wrote:
>> On 2022-01-11 16:40, Vagrant Cascadian wrote:
>>> On 2022-01-11, Lennart Sorensen wrote:
>>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
>>> >> Something in the toolchain recently changed which causes u-boot arch:all
>>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
>>> >> works fine where binutils hasn't yet migrated.
>>> >> 
>>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
>>> >> 
>>> >> Full log:
>>> >> 
>>> >>   
>>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
>>> >> 
>>> >> The hopefully relevent lines from the build log:
...
>>> >> {standard input}: Assembler messages:
>>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
>>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
>>> >> {standard input}:821: Error: unrecognized opcode: `msync'
>>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
>>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
>>> >> make[4]: *** [/<>/scripts/Makefile.build:253: 
>>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
>>> >> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] 
>>> >> Error 2
>>> >> make[3]: *** Waiting for unfinished jobs
>>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> ...
>>> The binutils versions appear to be:
>>> 
>>>   succeeding, bookworm 2.37-10.1
>>>   failing, sid 2.37.50.20220106-2
>>> 
>>
>> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
>> the binutils side [1], which changes the behavior of `.machine`
>> directives to override, rather than augment, the base CPU. GCC is called
>> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
>> side, but as the default GCC machine is ppc, a `.set machine ppc` is
>> emitted at the beginning of the assembly code.
>>
>> One option would be to force the CPU to e500 on the GCC side, however
>> support for it has been removed. The options is therefore to force the
>> machine in the assembly code. This is what the attached patch does.
>
> Somehow I missed that you had attached a patch! I will try to get this
> tested and uploaded to Debian soon...

Your patch fixed building qemu-ppce500, but now I think we have a
potentially similar problem with qemu-riscv64 and qemu-riscv64_smode:

/<>/arch/riscv/cpu/cpu.c: Assembler messages:
/<>/arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode
  `csrs sstatus,a5'
/<>/arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode
  `csrw 0x003,0'
make[4]: *** [/<>/scripts/Makefile.build:254:
  arch/riscv/cpu/cpu.o] Error 1
make[3]: *** [/<>/Makefile:1810: arch/riscv/cpu] Error 2
make[3]: Leaving directory
  '/<>/debian/build/qemu-riscv64_smode'


live well,
  vagrant


>> --- u-boot-2022.01+dfsg.orig/arch/powerpc/cpu/mpc85xx/tlb.c
>> +++ u-boot-2022.01+dfsg/arch/powerpc/cpu/mpc85xx/tlb.c
>> @@ -50,7 +50,10 @@ void read_tlbcam_entry(int idx, u32 *val
>>  u32 _mas1;
>>  
>>  mtspr(MAS0, FSL_BOOKE_MAS0(1, idx, 0));
>> -asm volatile("tlbre;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "tlbre;isync;\n"
>> + ".machine pop;\n");
>>  _mas1 = mfspr(MAS1);
>>  
>>  *valid = (_mas1 & MAS1_VALID);
>> @@ -109,7 +112,10 @@ void init_used_tlb_cams(void)
>>  /* walk all the entries */
>>  for (i = 0; i < num_cam; i++) {
>>  mtspr(MAS0, FSL_BOOKE_MAS0(1, i, 0));
>> -asm volatile("tlbre;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "tlbre;isync;\n"
>> + ".machine pop;");
>>  if (mfspr(MAS1) & MAS1_VALID)
>>  use_tlb_cam(i);
>>  }
>> @@ -183,7 +189,10 @@ void disable_tlb(u8 esel)
>>  #ifdef CONFIG_ENABLE_36BIT_PHYS
>>  mtspr(MAS7, 0);
>>  #endif
>> -asm volatile("isync;msync;tlbwe;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "isync;msync;tlbwe;isync;\n"
>> + ".machine pop;\n");
>>  
>>  #ifdef CONFIG_ADDR_MAP
>>  if (gd->flags & GD_FLG_RELOC)
>> @@ -193,7 +202,11 @@ void disable_tlb(u8 esel)
>>  
>>  static void tlbsx (const volatile unsigned *addr)
>>  {
>> -__asm__ __volatile__ ("tlbsx 0,%0" : : "r" (addr), "m" (*addr));
>> +__asm__ __volatile__ (".machine push;\n"
>> +  ".machine e500;\n"
>> +  "tlbsx 0,%0;\n"
>> +  ".machine pop;\n"
>> +  : : "r" (addr), "m" (*addr));
>>  }
>>  
>>  /* return -1 if we didn't find anything */


signature.asc
Description: PGP signature


Re: [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update

2022-01-25 Thread Masami Hiramatsu
BTW, the original code comes from EDK2 implementation.
It seems that this INITIATE_RESET flag meaning in EDK2 is a bit different
from what we thought here. The flag is only used for resetting system via
UpdateCapsule() EFI call. The capsule update process itself will be done
at the boot time and warm reset soon after that.
(See HandleCapsules()@ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c)

Is it OK to change the INITIATE_RESET flag means? or should we forcibly
reset the system if we succeeded to update capsule on boot time?
(note that capsule on disk must be done at boot time in U-Boot)

Thank you,

2022年1月26日(水) 7:31 Masami Hiramatsu :
>
> Hi Takahiro,
>
> 2022年1月25日(火) 21:49 AKASHI Takahiro :
> >
> > Hi Masami,
> >
> > Thank you for this enhancement.
> >
> > On Tue, Jan 25, 2022 at 08:31:29PM +0900, Masami Hiramatsu wrote:
> > > Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after
> > > updating firmware. Note that the machine will reboot soon after
> > > applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET
> > > flag. If there are multiple capsules and one has this flag, the
> > > machine may reboot while scanning the capsule files.
> > > You can control when the machine reboot by renaming the capsule
> > > file because the capsule files will be applied alphabetically.
> > >
> > > Signed-off-by: Masami Hiramatsu 
> > > ---
> > >  lib/efi_loader/efi_capsule.c |   13 +
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > index 4463ae00fd..24a2a026a9 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware(
> > >   struct efi_firmware_management_protocol *fmp;
> > >   u16 *abort_reason;
> > >   efi_status_t ret = EFI_SUCCESS;
> > > + bool reset = false;
> > >
> > >   /* sanity check */
> > >   if (capsule_data->header_size < sizeof(*capsule) ||
> > >   capsule_data->header_size >= capsule_data->capsule_image_size)
> > >   return EFI_INVALID_PARAMETER;
> > >
> > > + if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) {
> > > + /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag */
> > > + if (!(capsule_data->flags & 
> > > CAPSULE_FLAGS_PERSIST_ACROSS_RESET))
> > > + return EFI_INVALID_PARAMETER;
> > > + reset = true;
> > > + }
> > > +
> > >   capsule = (void *)capsule_data + capsule_data->header_size;
> > >   capsule_size = capsule_data->capsule_image_size
> > >   - capsule_data->header_size;
> > > @@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware(
> > >  out:
> > >   efi_free_pool(handles);
> > >
> > > + if (ret == EFI_SUCCESS && reset) {
> > > + log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. 
> > > Reboot machine.\n");
> > > + do_reset(NULL, 0, 0, NULL);
> >
> > I don't think this is the right place of calling do_reset().
> > Whenever you have processed any capsule file, you have to
> >  - delete the capsule file,
> >  - create/update "Capsule" and "CapsuleLast" variables, and
> >  - modify ESRT table
> > before initiating a reset.
>
> Oops, indeed. Let me update the patch.
> Thank you!
>
> >
> > -Takahiro Akashi
> >
> > > + }
> > > +
> > >   return ret;
> > >  }
> > >  #else
> > >
>
>
>
> --
> Masami Hiramatsu



-- 
Masami Hiramatsu


Re: [PATCH 08/11] configs: sunxi: Add common SUNIV header

2022-01-25 Thread Andre Przywara
On Tue,  4 Jan 2022 19:35:05 -0500
Jesse Taube  wrote:

Hi,

> From: Icenowy Zheng 
> 
> Adds support for SUNIV and the F1C100s.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 
> ---
>  include/configs/suniv.h| 14 +++
>  include/configs/sunxi-common.h | 67 --
>  2 files changed, 62 insertions(+), 19 deletions(-)
>  create mode 100644 include/configs/suniv.h
> 
> diff --git a/include/configs/suniv.h b/include/configs/suniv.h
> new file mode 100644
> index 00..6118cd5e1a
> --- /dev/null
> +++ b/include/configs/suniv.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Configuration settings for new Allwinner F-series (suniv) CPU
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/*
> + * Include common sunxi configuration where most the settings are
> + */
> +#include 
> +
> +#endif /* __CONFIG_H */
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 7260eb72a4..62004a09c1 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -22,7 +22,12 @@
>  /* Serial & console */
>  #define CONFIG_SYS_NS16550_SERIAL
>  /* ns16550 reg in the low bits of cpu reg */
> +#ifndef CONFIG_MACH_SUNIV

Can you flip this around to avoid the negative logic?

>  #define CONFIG_SYS_NS16550_CLK   2400
> +#else
> +/* suniv doesn't have apb2 and uart is connected to apb1 */
> +#define CONFIG_SYS_NS16550_CLK   1
> +#endif
>  #ifndef CONFIG_DM_SERIAL
>  # define CONFIG_SYS_NS16550_REG_SIZE -4
>  # define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE
> @@ -49,6 +54,16 @@
>   * since it needs to fit in with the other values. By also #defining it
>   * we get warnings if the Kconfig value mismatches. */
>  #define CONFIG_SPL_BSS_START_ADDR0x2ff8
> +#elif defined(CONFIG_MACH_SUNIV)
> +#define SDRAM_OFFSET(x) 0x8##x
> +#define CONFIG_SYS_SDRAM_BASE0x8000
> +#define CONFIG_SYS_LOAD_ADDR 0x8100 /* default load address */

I am not sure this actually works? SYS_LOAD_ADDR lives in /Kconfig, you
would need to add a line there.

> +/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here
> + * since it needs to fit in with the other values. By also #defining it
> + * we get warnings if the Kconfig value mismatches.
> + */
> +#define CONFIG_SPL_STACK_R_ADDR  0x81e0
> +#define CONFIG_SPL_BSS_START_ADDR0x81f8
>  #else
>  #define SDRAM_OFFSET(x) 0x4##x
>  #define CONFIG_SYS_SDRAM_BASE0x4000
> @@ -109,6 +124,8 @@
>  #endif
>  
>  #define CONFIG_SYS_MMC_MAX_DEVICE4
> +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH)
> +#define CONFIG_ENV_SECT_SIZE 0x1000

This lives in Kconfig, and should not be needed anyway. I think this
gets covered by my SPI fix series? Please remove those two lines.

>  #endif
>  
>  /*
> @@ -187,32 +204,44 @@
>  #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0))
>  
>  #else
> -/*
> - * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc.
> - * 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
> - * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end.
> - */
> -#ifndef CONFIG_MACH_SUN8I_V3S
> -#define BOOTM_SIZE__stringify(0xa00)
> -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200))
> -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300))
> -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310))
> -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320))
> -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330))
> -#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340))
> -#else
> +#if defined(CONFIG_MACH_SUN8I_V3S)

Please merge this with the #else above into an #elif.

>  /*
>   * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc.
>   * 16M uncompressed kernel, 8M compressed kernel, 1M fdt,
>   * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end.
>   */
> -#define BOOTM_SIZE__stringify(0x2e0)
> -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(100))
> -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(180))
> -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(190))
> -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1A0))
> +#define BOOTM_SIZE __stringify(0x2e0)
> +#define KERNEL_ADDR_R  __stringify(SDRAM_OFFSET(100))
> +#define FDT_ADDR_R __stringify(SDRAM_OFFSET(180))
> +#define SCRIPT_ADDR_R  __stringify(SDRAM_OFFSET(190))

This part should vanish: the alignment is off, and PXEFILE_ADDR_R got
dropped. I guess a rebase artefact ...

>  #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1B0))
>  #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(1C0))
> +#elif defined(CONFIG_MACH_SUNIV)

Please add an empty line above that one, to separate the SoC classes.

> +/*
> + * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc.
> + * 8M uncompressed 

Re: [PATCH 05/11] ARM: sunxi: Add support for F1C100s

2022-01-25 Thread Andre Przywara
On Tue,  4 Jan 2022 19:35:02 -0500
Jesse Taube  wrote:

Hi,

can you please change the subject, to maybe mention clocks? Reads
rather generic as is.

> From: Icenowy Zheng 
> 
> This patch aims to add header files for the F1C100s.
> The header files included add support for gpio, dram and clocks.

This looks to be about clocks and UARTs only?

> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 
> ---
>  arch/arm/include/asm/arch-sunxi/clock.h   |  2 +-
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 +++
>  arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |  8 ++
>  arch/arm/include/asm/arch-sunxi/gpio.h|  1 +
>  4 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
> b/arch/arm/include/asm/arch-sunxi/clock.h
> index cbbe5c7a1e..2cfd540742 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
> @@ -19,7 +19,7 @@
>  #elif defined(CONFIG_SUN50I_GEN_H6)
>  #include 
>  #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
> -  defined(CONFIG_MACH_SUN50I)
> +  defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUNIV)
>  #include 
>  #elif defined(CONFIG_MACH_SUN9I)
>  #include 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index ee387127f3..5ecdf58bd5 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -168,6 +168,14 @@ struct sunxi_ccm_reg {
>   u32 pll_lock_ctrl;  /* 0x320 PLL lock control, R40 only */
>  };
>  
> +/* apb1 bit field */
> +#ifdef CONFIG_MACH_SUNIV
> +#define APB1_GATE_UART_SHIFT (20)
> +#define APB1_GATE_UART_MASK  (0x7 << APB1_GATE_UART_SHIFT)
> +#define APB1_GATE_TWI_SHIFT  (16)
> +#define APB1_GATE_TWI_MASK   (0x7 << APB1_GATE_TWI_SHIFT)

The values match the user manual, but I don't see the *_MASK values used
anywhere. Please just drop them.

> +#endif
> +
>  /* apb2 bit field */
>  #define APB2_CLK_SRC_LOSC(0x0 << 24)
>  #define APB2_CLK_SRC_OSC24M  (0x1 << 24)
> @@ -226,7 +234,12 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL5_CTRL_SIGMA_DELTA_EN (0x1 << 24)
>  #define CCM_PLL5_CTRL_EN (0x1 << 31)
>  
> +#if !defined(CONFIG_MACH_SUNIV)
>  #define PLL6_CFG_DEFAULT 0x90041811 /* 600 MHz */
> +#else
> +/* suniv pll6 doesn't have postdiv 2, so k is set to 0 */
> +#define PLL6_CFG_DEFAULT 0x90041800

The manual says that bit 0 resets to 1, as in the other SoCs. It just
seems to affect the "back door clock output", so we should leave it as
1.

> +#endif
>  
>  #define CCM_PLL6_CTRL_N_SHIFT8
>  #define CCM_PLL6_CTRL_N_MASK (0x1f << CCM_PLL6_CTRL_N_SHIFT)
> @@ -310,6 +323,8 @@ struct sunxi_ccm_reg {
>  #define AHB_GATE_OFFSET_USB0 25
>  #define AHB_GATE_OFFSET_SATA 24
>  #endif
> +#define AHB_GATE_OFFSET_SPI1 21
> +#define AHB_GATE_OFFSET_SPI0 20

I think this is legacy, we don't need this anymore with the DM clock
driver we use in the SPI driver. The SPL SPI is separate anyway.
Please just drop.

>  #define AHB_GATE_OFFSET_MCTL 14
>  #define AHB_GATE_OFFSET_GMAC 17
>  #define AHB_GATE_OFFSET_NAND013
> @@ -458,6 +473,8 @@ struct sunxi_ccm_reg {
>  #ifdef CONFIG_MACH_SUN8I_R40
>  #define AHB_RESET_OFFSET_SATA24
>  #endif
> +#define AHB_RESET_OFFSET_SPI121
> +#define AHB_RESET_OFFSET_SPI020

Same here, I don't see that used anywhere.

>  #define AHB_RESET_OFFSET_GMAC17
>  #define AHB_RESET_OFFSET_MCTL14
>  #define AHB_RESET_OFFSET_MMC311
> @@ -488,6 +505,14 @@ struct sunxi_ccm_reg {
>  #define AHB_RESET_OFFSET_EPHY2
>  #define AHB_RESET_OFFSET_LVDS0
>  
> +/* apb1 reset */
> +#ifdef CONFIG_MACH_SUNIV
> +#define APB1_RESET_UART_SHIFT(20)
> +#define APB1_RESET_UART_MASK (0x7 << APB1_RESET_UART_SHIFT)
> +#define APB1_RESET_TWI_SHIFT (16)
> +#define APB1_RESET_TWI_MASK  (0x7 << APB1_RESET_TWI_SHIFT)
> +#endif
> +
>  /* apb2 reset */
>  #define APB2_RESET_UART_SHIFT(16)
>  #define APB2_RESET_UART_MASK (0xff << APB2_RESET_UART_SHIFT)
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
> b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> index d4c795d89c..83178dd5c8 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> @@ -122,6 +122,12 @@ defined(CONFIG_MACH_SUN50I)
>  
>  #define SUNXI_SJTAG_BASE 0x01c23c00
>  
> +#ifdef CONFIG_MACH_SUNIV
> +#define SUNXI_UART0_BASE 0x01c25000
> +#define SUNXI_UART1_BASE 0x01c25400
> +#define SUNXI_UART2_BASE 0x01c25800
> +#endif

That should be moved down and merged into the other chunk below.

Rest looks alright.


Re: i.MX8MN (ROMv2) fails to boot over USB

2022-01-25 Thread Tim Harvey
On Tue, Jan 25, 2022 at 3:49 PM Adam Ford  wrote:
>
> I have a flash.bin file that boots over MMC just fine, but when I use
> that same flash.bin file, it appears to hang after running ATF.  I
> dumped some debug info for printing the handling of the FIT file, and
> I noticed the fit read sizes are also not consistent between MMC and
> USB loads with the identical flash.bin.
>
> MMC booting is calling spl_romapi_raw_seekable_read, but the USB
> booting is not.  Maybe this is normal.
>
> I was hoping someone might have some pointers on how I can
> troubleshoot this.  It's also weird to me that the various nodes are
> listed twice in the USB boot, but not the MMC boot.
>
> I have poked around in the spl_imx_romapi.c file, but I am not seeing
> anything obvious.
>
> SPL and ATF are executing, so it's partially decoding the FIT file and
> executing those two pieces correctly from what I can see.
>
> USB log (no FDT)
> U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600)
> WDT:   Started watchdog@3028 with servicing (60s timeout)
> Trying to boot from BOOTROM
> Find img info 0x&48027600, size 872
> Need continue download 1024
> fit read sector 48027600, sectors=872, dst=42206c40, count=872, size=0x368
> firmware: 'uboot'
> External data: dst=4020, offset=3000, size=a4d98
> fdt: 'fdt'
> External data: dst=402a4dc0, offset=b1e60, size=af68
> loadables: 'atf'
> External data: dst=96, offset=a7d98, size=a0c6
> no string for index 1
> Download 772040, Total size 773576
> fit read sector 48027600, sectors=872, dst=42206fb0, count=872, size=0x368
> firmware: 'uboot'
> External data: dst=4020, offset=3000, size=a4d98
> fdt: 'fdt'
> External data: dst=402a4dc0, offset=b1e60, size=af68
> loadables: 'atf'
> External data: dst=96, offset=a7d98, size=a0c6
> no string for index 1
> NOTICE:  BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9
> NOTICE:  BL31: Built : 14:45:34, Jan 25 2022
>
> 
>
> MMC Booting Log (with DTB):
>
> U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600)
> WDT:   Started watchdog@3028 with servicing (60s timeout)
> Trying to boot from BOOTROM
> image offset 0x8000, pagesize 0x200, ivt offset 0x0
> ROM API load from 0x6, size 0x400
> spl_romapi_raw_seekable_read 0x6, size 0x400
> fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368
> firmware: 'uboot'
> ROM API load from 0x63000, size 0xa4e00
> spl_romapi_raw_seekable_read 0x63000, size 0xa4e00
> External data: dst=4020, offset=3000, size=a4d98
> fdt: 'fdt'
> ROM API load from 0x111e00, size 0xb000
> spl_romapi_raw_seekable_read 0x111e00, size 0xb000
> External data: dst=402a4dc0, offset=b1e60, size=af68
> loadables: 'atf'
> ROM API load from 0x107c00, size 0xa400
> spl_romapi_raw_seekable_read 0x107c00, size 0xa400
> External data: dst=96, offset=a7d98, size=a0c6
> no string for index 1
> NOTICE:  BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9
> NOTICE:  BL31: Built : 14:45:34, Jan 25 2022
>
> 

Adam,

I've previously run into this as well and unfortunately have no
solution. Note that I had to hack in some support to the SPL for USB
which I assume you've done as well. If I recall trying to enable
DM_USB for the SPL took too much space so that hacks I had revolved
around getting it to work in the non-DM fashion.

Best regards,

Tim


Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

2022-01-25 Thread Vagrant Cascadian
A bug in Debian is causing a build failure of the qemu-ppce500 target:

  https://bugs.debian.org/1003490

I've CCed u-boot in case they're not aware of the issue.

Some background follows...

On 2022-01-15, Aurelien Jarno wrote:
> On 2022-01-11 16:40, Vagrant Cascadian wrote:
>> On 2022-01-11, Lennart Sorensen wrote:
>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
>> >> Something in the toolchain recently changed which causes u-boot arch:all
>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
>> >> works fine where binutils hasn't yet migrated.
>> >> 
>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
>> >> 
>> >> Full log:
>> >> 
>> >>   
>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
>> >> 
>> >> The hopefully relevent lines from the build log:
>> >> 
>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/cpu/mpc85xx/.tlb.o.d 
>> >> -nostdinc -isystem /usr/lib/gcc-cross/powerpc-linux-gnu/11/include 
>> >> -Iinclude  -I/<>/include  
>> >> -I/<>/arch/powerpc/include -include 
>> >> /<>/include/linux/kconfig.h  
>> >> -I/<>/arch/powerpc/cpu/mpc85xx -Iarch/powerpc/cpu/mpc85xx 
>> >> -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security 
>> >> -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing 
>> >> -fno-PIE -Os -fno-stack-protector -fno-delete-null-pointer-checks 
>> >> -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds 
>> >> -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized 
>> >> -fmacro-prefix-map=/<>/= -g -fstack-usage 
>> >> -Wno-format-nonliteral -Wno-address-of-packed-member 
>> >> -Wno-unused-but-set-variable -Werror=date-time -Wno-packed-not-aligned 
>> >> -D__powerpc__ -ffixed-r2 -m32 -fno-ira-hoist-pressure -Wa,-me500 
>> >> -msoft-float -mno-string -fpic -mrelocatable -ffunction-sections 
>> >> -fdata-sections -mcall-linux -msingle-pic-base -fno-jump-tables -pipe
>> >> -DKBUILD_BASENAME='"tlb"'  -DKBUILD_MODNAME='"tlb"' -c -o 
>> >> arch/powerpc/cpu/mpc85xx/tlb.o 
>> >> /<>/arch/powerpc/cpu/mpc85xx/tlb.c
>> >> ...
>> >> {standard input}: Assembler messages:
>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:821: Error: unrecognized opcode: `msync'
>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
>> >> make[4]: *** [/<>/scripts/Makefile.build:253: 
>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
>> >> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] 
>> >> Error 2
>> >> make[3]: *** Waiting for unfinished jobs
>> >>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
...
>> The binutils versions appear to be:
>> 
>>   succeeding, bookworm 2.37-10.1
>>   failing, sid 2.37.50.20220106-2
>> 
>
> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
> the binutils side [1], which changes the behavior of `.machine`
> directives to override, rather than augment, the base CPU. GCC is called
> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
> side, but as the default GCC machine is ppc, a `.set machine ppc` is
> emitted at the beginning of the assembly code.
>
> One option would be to force the CPU to e500 on the GCC side, however
> support for it has been removed. The options is therefore to force the
> machine in the assembly code. This is what the attached patch does.

Somehow I missed that you had attached a patch! I will try to get this
tested and uploaded to Debian soon...

live well,
  vagrant

> --- u-boot-2022.01+dfsg.orig/arch/powerpc/cpu/mpc85xx/tlb.c
> +++ u-boot-2022.01+dfsg/arch/powerpc/cpu/mpc85xx/tlb.c
> @@ -50,7 +50,10 @@ void read_tlbcam_entry(int idx, u32 *val
>   u32 _mas1;
>  
>   mtspr(MAS0, FSL_BOOKE_MAS0(1, idx, 0));
> - asm volatile("tlbre;isync");
> + asm volatile(".machine push;\n"
> +  ".machine e500;\n"
> +  "tlbre;isync;\n"
> +  ".machine pop;\n");
>   _mas1 = mfspr(MAS1);
>  
>   *valid = (_mas1 & MAS1_VALID);
> @@ -109,7 +112,10 @@ void init_used_tlb_cams(void)
>   /* walk all the entries */
>   for (i = 0; i < num_cam; i++) {
>   mtspr(MAS0, FSL_BOOKE_MAS0(1, i, 0));
> - asm volatile("tlbre;isync");
> + asm volatile(".machine push;\n"
> +  ".machine e500;\n"
> +  "tlbre;isync;\n"
> +  ".machine pop;");
>   if (mfspr(MAS1) & MAS1_VALID)
>   use_tlb_cam(i);
>   }
> @@ -183,7 +189,10 @@ void disable_tlb(u8 esel)
>  #ifdef CONFIG_ENABLE_36BIT_PHYS
>   mtspr(MAS7, 0);
>  #endif
> - asm volatile("isync;msync;tlbwe;isync");
> + asm volatile(".machine push;\n"
> +  ".machine e500;\n"
> +  

Re: [PATCH 0/5] sunxi: remove lowlevel_init

2022-01-25 Thread Jesse Taube




On 1/25/22 18:47, Jesse Taube wrote:



On 1/24/22 20:15, Andre Przywara wrote:

For a long time the Allwinner platform was using the lowlevel_init()
routine in U-Boot's boot process, even though there did not seem to be
a real need for that. The README file suggests it should only be used
for "bare minimum" tasks to reach board_init_f(). The routines called
in arch/arm/mach-sunxi/board.c:s_init() did nothing that really
warranted the early and special execution. Since we always run with an
SPL, the board_init_f() routine in there seems to be the right place
for early peripherals initialisation.
Having those routines in s_init() actually forced other parts of U-Boot
to follow suit: for instance we added a lowlevel_init() function to the
armv8 side, just for sunxi. The same game seems to repeat for the
ARM9 support we need for the F1C100s chip, and possibly for the RISC-V
part as well.

To avoid this and to cleanup some code on the way, remove the need for
lowlevel_init for sunxi completely, by:
- moving the early peripheral init (clocks, timer, pinmux) to
board_init_f(). This also avoids executing those bits a second time when
we boot up U-Boot proper. (patch 1/5)
- move the "SRAM setup" bits for just a few old SoCs into a separate file,
and include this only if needed. (patch 3/5)
- move the ACTLR.SMPEN bit setting from board.c into start.S, because we
actually need to set this bit early. Other platforms should be able to
scrap their own copies and piggy back on this change. (patch 2/5)
This allows us to actually remove the lowlevel_init.S file from armv8 in
patch 4/5, as sunxi was the only user.
For good measure, we also clean up some bits in sunxi_common.h. (patch 5/5)

I compile tested this for all sunxi boards, and boot tested (into Linux) on
Pine64, PineH64, BananaPi M1, OrangePi Zero. But there is a high chance of
something breaking, so please give it a good shake on whatever Allwinner
hardware you have access to.

Thanks,
Andre

Andre Przywara (5):
sunxi: move non-essential code out of s_init()
sunxi: move Cortex SMPEN setting into start.S
sunxi: move early "SRAM setup" into separate file
armv8: remove no longer needed lowlevel_init.S
sunxi-common.h: remove pointless #ifdefs

   arch/arm/Kconfig   |  3 --
   arch/arm/cpu/armv7/Kconfig |  7 +++
   arch/arm/cpu/armv7/start.S | 11 +
   arch/arm/cpu/armv7/sunxi/Makefile  |  3 ++
   arch/arm/cpu/armv7/sunxi/sram.c| 45 +
   arch/arm/cpu/armv8/Makefile|  1 -
   arch/arm/cpu/armv8/lowlevel_init.S | 43 
   arch/arm/mach-sunxi/Kconfig|  2 -
   arch/arm/mach-sunxi/board.c| 78 --
   include/configs/sunxi-common.h |  7 ---
   10 files changed, 86 insertions(+), 114 deletions(-)
   create mode 100644 arch/arm/cpu/armv7/sunxi/sram.c
   delete mode 100644 arch/arm/cpu/armv8/lowlevel_init.S



Tested-By: Jesse Taube 

Tested on Lamobo_R1_defconfig.


Tested on Lamobo_R1_defconfig and f1c100s.



Thanks,
Jesse Taube


i.MX8MN (ROMv2) fails to boot over USB

2022-01-25 Thread Adam Ford
I have a flash.bin file that boots over MMC just fine, but when I use
that same flash.bin file, it appears to hang after running ATF.  I
dumped some debug info for printing the handling of the FIT file, and
I noticed the fit read sizes are also not consistent between MMC and
USB loads with the identical flash.bin.

MMC booting is calling spl_romapi_raw_seekable_read, but the USB
booting is not.  Maybe this is normal.

I was hoping someone might have some pointers on how I can
troubleshoot this.  It's also weird to me that the various nodes are
listed twice in the USB boot, but not the MMC boot.

I have poked around in the spl_imx_romapi.c file, but I am not seeing
anything obvious.

SPL and ATF are executing, so it's partially decoding the FIT file and
executing those two pieces correctly from what I can see.

USB log (no FDT)
U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600)
WDT:   Started watchdog@3028 with servicing (60s timeout)
Trying to boot from BOOTROM
Find img info 0x&48027600, size 872
Need continue download 1024
fit read sector 48027600, sectors=872, dst=42206c40, count=872, size=0x368
firmware: 'uboot'
External data: dst=4020, offset=3000, size=a4d98
fdt: 'fdt'
External data: dst=402a4dc0, offset=b1e60, size=af68
loadables: 'atf'
External data: dst=96, offset=a7d98, size=a0c6
no string for index 1
Download 772040, Total size 773576
fit read sector 48027600, sectors=872, dst=42206fb0, count=872, size=0x368
firmware: 'uboot'
External data: dst=4020, offset=3000, size=a4d98
fdt: 'fdt'
External data: dst=402a4dc0, offset=b1e60, size=af68
loadables: 'atf'
External data: dst=96, offset=a7d98, size=a0c6
no string for index 1
NOTICE:  BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9
NOTICE:  BL31: Built : 14:45:34, Jan 25 2022



MMC Booting Log (with DTB):

U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600)
WDT:   Started watchdog@3028 with servicing (60s timeout)
Trying to boot from BOOTROM
image offset 0x8000, pagesize 0x200, ivt offset 0x0
ROM API load from 0x6, size 0x400
spl_romapi_raw_seekable_read 0x6, size 0x400
fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368
firmware: 'uboot'
ROM API load from 0x63000, size 0xa4e00
spl_romapi_raw_seekable_read 0x63000, size 0xa4e00
External data: dst=4020, offset=3000, size=a4d98
fdt: 'fdt'
ROM API load from 0x111e00, size 0xb000
spl_romapi_raw_seekable_read 0x111e00, size 0xb000
External data: dst=402a4dc0, offset=b1e60, size=af68
loadables: 'atf'
ROM API load from 0x107c00, size 0xa400
spl_romapi_raw_seekable_read 0x107c00, size 0xa400
External data: dst=96, offset=a7d98, size=a0c6
no string for index 1
NOTICE:  BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9
NOTICE:  BL31: Built : 14:45:34, Jan 25 2022




Re: [PATCH 0/5] sunxi: remove lowlevel_init

2022-01-25 Thread Jesse Taube




On 1/24/22 20:15, Andre Przywara wrote:

For a long time the Allwinner platform was using the lowlevel_init()
routine in U-Boot's boot process, even though there did not seem to be
a real need for that. The README file suggests it should only be used
for "bare minimum" tasks to reach board_init_f(). The routines called
in arch/arm/mach-sunxi/board.c:s_init() did nothing that really
warranted the early and special execution. Since we always run with an
SPL, the board_init_f() routine in there seems to be the right place
for early peripherals initialisation.
Having those routines in s_init() actually forced other parts of U-Boot
to follow suit: for instance we added a lowlevel_init() function to the
armv8 side, just for sunxi. The same game seems to repeat for the
ARM9 support we need for the F1C100s chip, and possibly for the RISC-V
part as well.

To avoid this and to cleanup some code on the way, remove the need for
lowlevel_init for sunxi completely, by:
- moving the early peripheral init (clocks, timer, pinmux) to
   board_init_f(). This also avoids executing those bits a second time when
   we boot up U-Boot proper. (patch 1/5)
- move the "SRAM setup" bits for just a few old SoCs into a separate file,
   and include this only if needed. (patch 3/5)
- move the ACTLR.SMPEN bit setting from board.c into start.S, because we
   actually need to set this bit early. Other platforms should be able to
   scrap their own copies and piggy back on this change. (patch 2/5)
This allows us to actually remove the lowlevel_init.S file from armv8 in
patch 4/5, as sunxi was the only user.
For good measure, we also clean up some bits in sunxi_common.h. (patch 5/5)

I compile tested this for all sunxi boards, and boot tested (into Linux) on
Pine64, PineH64, BananaPi M1, OrangePi Zero. But there is a high chance of
something breaking, so please give it a good shake on whatever Allwinner
hardware you have access to.

Thanks,
Andre

Andre Przywara (5):
   sunxi: move non-essential code out of s_init()
   sunxi: move Cortex SMPEN setting into start.S
   sunxi: move early "SRAM setup" into separate file
   armv8: remove no longer needed lowlevel_init.S
   sunxi-common.h: remove pointless #ifdefs

  arch/arm/Kconfig   |  3 --
  arch/arm/cpu/armv7/Kconfig |  7 +++
  arch/arm/cpu/armv7/start.S | 11 +
  arch/arm/cpu/armv7/sunxi/Makefile  |  3 ++
  arch/arm/cpu/armv7/sunxi/sram.c| 45 +
  arch/arm/cpu/armv8/Makefile|  1 -
  arch/arm/cpu/armv8/lowlevel_init.S | 43 
  arch/arm/mach-sunxi/Kconfig|  2 -
  arch/arm/mach-sunxi/board.c| 78 --
  include/configs/sunxi-common.h |  7 ---
  10 files changed, 86 insertions(+), 114 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/sunxi/sram.c
  delete mode 100644 arch/arm/cpu/armv8/lowlevel_init.S



Tested-By: Jesse Taube 

Tested on Lamobo_R1_defconfig.

Thanks,
Jesse Taube


Re: [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update

2022-01-25 Thread Masami Hiramatsu
Hi Takahiro,

2022年1月25日(火) 21:49 AKASHI Takahiro :
>
> Hi Masami,
>
> Thank you for this enhancement.
>
> On Tue, Jan 25, 2022 at 08:31:29PM +0900, Masami Hiramatsu wrote:
> > Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after
> > updating firmware. Note that the machine will reboot soon after
> > applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET
> > flag. If there are multiple capsules and one has this flag, the
> > machine may reboot while scanning the capsule files.
> > You can control when the machine reboot by renaming the capsule
> > file because the capsule files will be applied alphabetically.
> >
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  lib/efi_loader/efi_capsule.c |   13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 4463ae00fd..24a2a026a9 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware(
> >   struct efi_firmware_management_protocol *fmp;
> >   u16 *abort_reason;
> >   efi_status_t ret = EFI_SUCCESS;
> > + bool reset = false;
> >
> >   /* sanity check */
> >   if (capsule_data->header_size < sizeof(*capsule) ||
> >   capsule_data->header_size >= capsule_data->capsule_image_size)
> >   return EFI_INVALID_PARAMETER;
> >
> > + if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) {
> > + /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag */
> > + if (!(capsule_data->flags & 
> > CAPSULE_FLAGS_PERSIST_ACROSS_RESET))
> > + return EFI_INVALID_PARAMETER;
> > + reset = true;
> > + }
> > +
> >   capsule = (void *)capsule_data + capsule_data->header_size;
> >   capsule_size = capsule_data->capsule_image_size
> >   - capsule_data->header_size;
> > @@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware(
> >  out:
> >   efi_free_pool(handles);
> >
> > + if (ret == EFI_SUCCESS && reset) {
> > + log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. 
> > Reboot machine.\n");
> > + do_reset(NULL, 0, 0, NULL);
>
> I don't think this is the right place of calling do_reset().
> Whenever you have processed any capsule file, you have to
>  - delete the capsule file,
>  - create/update "Capsule" and "CapsuleLast" variables, and
>  - modify ESRT table
> before initiating a reset.

Oops, indeed. Let me update the patch.
Thank you!

>
> -Takahiro Akashi
>
> > + }
> > +
> >   return ret;
> >  }
> >  #else
> >



-- 
Masami Hiramatsu


Re: [PATCH] arm: kirkwood: Pogoplug V4 : Use Marvel network PHY driver

2022-01-25 Thread Tony Dinh
Hi Stefan,

On Tue, Jan 25, 2022 at 7:49 AM Stefan Roese  wrote:
>
> On 1/25/22 10:48, Tony Dinh wrote:
> > The Pogoplug V4 board has the network chip Marvell 88E1118R. So to
> > properly configure the network, enable CONFIG_PHY_MARVELL to activate
> > the driver M88E1118R.
> >
> > - This patch depends on the series:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220124061712.28316-2-mibo...@gmail.com/
> >
> > Signed-off-by: Tony Dinh 
>
> I was wondering, how all this "magically" works without the Marvell PHY
> driver being involved. ;) So:

I was wondering the same thing :) so I traced the mvgbe uclass code
calling sequence. It sets up the network in the same way for Marvell
network chips used in Kirkwood boards so the network was brought up
successfully. And it is because the driver .config hook falls back to
the genphy_config() in drivers/net/phy/phy.c. And there is enough
there for the network configuration. Hypothetically, if we encountered
an unknown chip, it still works in Gbit mode.

However, the specific settings such as RGMII and LED are done by the
driver .config and .startup hook if the Marvell PHY driver is enabled.

Initially, I thought if there is info in the DTS (or we could add
more), then this mvgbe uclass could do the work as the same as the
driver, too. But things such as phy-mode, speed, and duplex... must be
added to the DTS to make that happen. And it is counterproductive when
we already have the driver for that.

And thank you, Marek, and Pali for reviewing and critics. After many
years of absence from u-boot, I got up to speed again a lot easier
thanks to your comments!

Thanks,
Tony

> Reviewed-by: Stefan Roese 
>
> Thanks,
> Stefan
>
> > ---
> >
> >   configs/pogo_v4_defconfig | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
> > index 5490067b9e..1cf409c834 100644
> > --- a/configs/pogo_v4_defconfig
> > +++ b/configs/pogo_v4_defconfig
> > @@ -62,6 +62,7 @@ CONFIG_KIRKWOOD_GPIO=y
> >   CONFIG_MVEBU_MMC=y
> >   CONFIG_MTD=y
> >   CONFIG_MTD_RAW_NAND=y
> > +CONFIG_PHY_MARVELL=y
> >   CONFIG_DM_ETH=y
> >   CONFIG_MVGBE=y
> >   CONFIG_MII=y
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: Compile only changed files when doing 'make'?

2022-01-25 Thread Tom Rini
On Tue, Jan 25, 2022 at 03:50:43PM -, Grant Edwards wrote:

> I'm working on a Renesas supplied port of U-Boot, and it seems that
> 'make' always compiles every single (configured) source file instead
> compiling only the source files that have been changed since the
> previous 'make'.  I've never run into this before on projects that use
> 'make', and it makes development of U-Boot rather grueling.
> 
> Is that due to something Renesas broke?
> 
> Or is that a "feature" of the standard U-Boot Makefile?

So, it partly depends on what version of U-Boot that you're working on
top of.  It's still to me a relatively recent set of improvements that
fix a number of reproducible build changes and so that with a constant
SOURCE_DATE_EPOCH nothing is rebuilt that hasn't changed, and so it's
also true that re-running "make" only rebuilds the few files that would
change due to time stamp usage, which has also been corrected.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH u-boot-marvell 14/14] tools: kwboot: Set debug flag to 1

2022-01-25 Thread Marek Behún
From: Pali Rohár 

This should enable BootROM output on UART.

(At least on A385 BootROM this is broken, BootROM ignores this debug
 flag and does not enable its output on UART if some valid image is
 available in SPI-NOR.)

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 859559fb72..2684f0e75a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1631,6 +1631,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 * baudrate (which should be 115200) and do not touch
 * UART MPP configuration.
 */
+   hdr->flags |= 0x1;
hdr->options &= ~0x1F;
hdr->options |= MAIN_HDR_V1_OPT_BAUD_DEFAULT;
hdr->options |= 0 << 3;
-- 
2.34.1



[PATCH u-boot-marvell 13/14] tools: kwboot: Fix usage of -D without -t

2022-01-25 Thread Marek Behún
From: Pali Rohár 

When -D is specified then both bootmsg and debugmsg are not set, but
imgpath is set. Fix this check for valid and required parameters.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index fca1c73c55..859559fb72 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1819,7 +1819,7 @@ main(int argc, char **argv)
}
} while (1);
 
-   if (!bootmsg && !term && !debugmsg)
+   if (!bootmsg && !term && !debugmsg && !imgpath)
goto usage;
 
ttypath = argv[optind++];
-- 
2.34.1



[PATCH u-boot-marvell 11/14] tools: kwboot: Handle EINTR in kwboot_write()

2022-01-25 Thread Marek Behún
From: Pali Rohár 

The write() syscall may be interrupted. Handle EINTR and retry it.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index de433c1b04..8b748f0fdd 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -292,13 +292,15 @@ static int blk_rsp_timeo = KWBOOT_BLK_RSP_TIMEO;
 static ssize_t
 kwboot_write(int fd, const char *buf, size_t len)
 {
-   size_t tot = 0;
+   ssize_t tot = 0;
 
while (tot < len) {
ssize_t wr = write(fd, buf + tot, len - tot);
 
-   if (wr < 0)
-   return -1;
+   if (wr < 0 && errno == EINTR)
+   continue;
+   else if (wr < 0)
+   return wr;
 
tot += wr;
}
-- 
2.34.1



[PATCH u-boot-marvell 10/14] tools: kwboot: Remove 2s delay before sending first xmodem packet

2022-01-25 Thread Marek Behún
From: Pali Rohár 

This delay is not needed anymore since kwboot already handles retrying
logic for incomplete xmodem packets and also forces BootROM to flush its
input queue. Removing it decreases total transfer time.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 824ae005b2..de433c1b04 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1142,10 +1142,6 @@ kwboot_xmodem(int tty, const void *_img, size_t size, 
int baudrate)
 */
hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) % KWBOOT_XM_BLKSZ;
 
-   kwboot_printv("Waiting %d ms and flushing tty\n", blk_rsp_timeo);
-   usleep(blk_rsp_timeo * 1000);
-   tcflush(tty, TCIOFLUSH);
-
pnum = 1;
 
rc = kwboot_xmodem_one(tty, , 1, img, hdrsz, baudrate);
-- 
2.34.1



[PATCH u-boot-marvell 12/14] tools: kwboot: Handle EINTR in kwboot_tty_recv()

2022-01-25 Thread Marek Behún
From: Pali Rohár 

The select() and read() syscalls may be interrupted. Handle EINTR and
retry them.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 8b748f0fdd..fca1c73c55 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -409,15 +409,19 @@ kwboot_tty_recv(int fd, void *buf, size_t len, int timeo)
 
do {
nfds = select(fd + 1, , NULL, NULL, );
-   if (nfds < 0)
+   if (nfds < 0 && errno == EINTR)
+   continue;
+   else if (nfds < 0)
goto out;
-   if (!nfds) {
+   else if (!nfds) {
errno = ETIMEDOUT;
goto out;
}
 
n = read(fd, buf, len);
-   if (n <= 0)
+   if (n < 0 && errno == EINTR)
+   continue;
+   else if (n <= 0)
goto out;
 
buf = (char *)buf + n;
-- 
2.34.1



[PATCH u-boot-marvell 09/14] tools: kwboot: Force BootROM to flush input queue after boot pattern

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Force the BootROM to flush its input queue after sending boot pattern.

This ensures that after function kwboot_bootmsg() finishes, BootROM is
able to start receiving xmodem packets without any specific delay or
setup.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index c413a8bf51..824ae005b2 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -717,6 +717,7 @@ out:
 static int
 kwboot_bootmsg(int tty, void *msg)
 {
+   struct kwboot_block block;
int rc;
char c;
int count;
@@ -747,7 +748,40 @@ kwboot_bootmsg(int tty, void *msg)
 
kwboot_printv("\n");
 
-   return rc;
+   if (rc)
+   return rc;
+
+   /*
+* At this stage we have sent more boot message patterns and BootROM
+* (at least on Armada XP and 385) started interpreting sent bytes as
+* part of xmodem packets. If BootROM is expecting SOH byte as start of
+* a xmodem packet and it receives byte 0xff, then it throws it away and
+* sends a NAK reply to host. If BootROM does not receive any byte for
+* 2s when expecting some continuation of the xmodem packet, it throws
+* away the partially received xmodem data and sends NAK reply to host.
+*
+* Therefore for starting xmodem transfer we have two options: Either
+* wait 2s or send 132 0xff bytes (which is the size of xmodem packet)
+* to ensure that BootROM throws away any partially received data.
+*/
+
+   /* flush output queue with remaining boot message patterns */
+   tcflush(tty, TCOFLUSH);
+
+   /* send one xmodem packet with 0xff bytes to force BootROM to re-sync */
+   memset(, 0xff, sizeof(block));
+   kwboot_tty_send(tty, , sizeof(block), 0);
+
+   /*
+* Sending 132 bytes via 115200B/8-N-1 takes 11.45 ms, reading 132 bytes
+* takes 11.45 ms, so waiting for 30 ms should be enough.
+*/
+   usleep(30 * 1000);
+
+   /* flush remaining NAK replies from input queue */
+   tcflush(tty, TCIFLUSH);
+
+   return 0;
 }
 
 static int
-- 
2.34.1



[PATCH u-boot-marvell 08/14] tools: kwboot: Allow to use option -b without image path

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Allow option -b without image path parameter, to send boot pattern and
wait for response but not send any image. This allows to use kwboot just
for processing boot pattern and user can use any other xmodem tool for
transferring the image itself (e.g. sx). Useful for debugging purposes.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1dcec1969a..c413a8bf51 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1699,6 +1699,8 @@ main(int argc, char **argv)
size_t size;
size_t after_img_rsv;
int baudrate;
+   int prev_optind;
+   int c;
 
rv = 1;
tty = -1;
@@ -1716,22 +1718,32 @@ main(int argc, char **argv)
kwboot_verbose = isatty(STDOUT_FILENO);
 
do {
-   int c = getopt(argc, argv, "hb:ptaB:dD:q:s:o:");
+   prev_optind = optind;
+   c = getopt(argc, argv, "hbptaB:dD:q:s:o:");
if (c < 0)
break;
 
switch (c) {
case 'b':
+   if (imgpath || bootmsg || debugmsg)
+   goto usage;
bootmsg = kwboot_msg_boot;
-   imgpath = optarg;
+   if (prev_optind == optind)
+   goto usage;
+   if (argv[optind] && argv[optind][0] != '-')
+   imgpath = argv[optind++];
break;
 
case 'D':
+   if (imgpath || bootmsg || debugmsg)
+   goto usage;
bootmsg = NULL;
imgpath = optarg;
break;
 
case 'd':
+   if (imgpath || bootmsg || debugmsg)
+   goto usage;
debugmsg = kwboot_msg_debug;
break;
 
@@ -1774,11 +1786,11 @@ main(int argc, char **argv)
if (!bootmsg && !term && !debugmsg)
goto usage;
 
-   if (argc - optind < 1)
-   goto usage;
-
ttypath = argv[optind++];
 
+   if (optind != argc)
+   goto usage;
+
tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
if (tty < 0) {
perror(ttypath);
-- 
2.34.1



[PATCH u-boot-marvell 07/14] tools: kwboot: Show 'E' in progress output when error occurs

2022-01-25 Thread Marek Behún
From: Pali Rohár 

When kwboot is unable to resend current xmodem packet, show an 'E' in the
progress output instead of a '+'. This allows to distinguish between the
state when kwboot is retrying sending the packet and when retry is not
possible.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index dfac8aed7b..1dcec1969a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -975,8 +975,12 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, 
int allow_non_xm,
if (rc)
goto err;
 
-   if (!allow_non_xm && c != ACK)
-   kwboot_progress(-1, '+');
+   if (!allow_non_xm && c != ACK) {
+   if (c == NAK && allow_retries && retries + 1 < 16)
+   kwboot_progress(-1, '+');
+   else
+   kwboot_progress(-1, 'E');
+   }
} while (c == NAK && allow_retries && retries++ < 16);
 
if (non_xm_print)
-- 
2.34.1



[PATCH u-boot-marvell 06/14] tools: kwboot: Fix handling of repeated xmodem packets

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Unfortunately during some stages of xmodem transfer, A385 BootROM is not
able to handle repeated xmodem packets. So if an error occurs during that
stage, stop the transfer and return failure.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index a619a6c3c1..dfac8aed7b 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -946,7 +946,7 @@ kwboot_xm_recv_reply(int fd, char *c, int stop_on_non_xm,
 
 static int
 kwboot_xm_sendblock(int fd, struct kwboot_block *block, int allow_non_xm,
-   int *done_print, int baudrate)
+   int *done_print, int baudrate, int allow_retries)
 {
int non_xm_print, baud_changed;
int rc, err, retries;
@@ -977,7 +977,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int 
allow_non_xm,
 
if (!allow_non_xm && c != ACK)
kwboot_progress(-1, '+');
-   } while (c == NAK && retries++ < 16);
+   } while (c == NAK && allow_retries && retries++ < 16);
 
if (non_xm_print)
kwboot_printv("\n");
@@ -1044,8 +1044,30 @@ kwboot_xmodem_one(int tty, int *pnum, int header, const 
uint8_t *data,
 
last_block = (left <= blksz);
 
+   /*
+* Handling of repeated xmodem packets is completely broken in
+* Armada 385 BootROM - it completely ignores xmodem packet
+* numbers, they are only used for checksum verification.
+* BootROM can handle a retry of the xmodem packet only during
+* the transmission of kwbimage header and only if BootROM
+* itself sent NAK response to previous attempt (it does it on
+* checksum failure). During the transmission of kwbimage data
+* part, BootROM always expects next xmodem packet, even if it
+* sent NAK to previous attempt - there is absolutely no way to
+* repair incorrectly transmitted xmodem packet during kwbimage
+* data part upload. Also, if kwboot receives non-ACK/NAK
+* response (meaning that original BootROM response was damaged
+* on UART) there is no way to detect if BootROM accepted xmodem
+* packet or not and no way to check if kwboot could repeat the
+* packet or not.
+*
+* Stop transfer and return failure if kwboot receives unknown
+* reply if non-xmodem reply is not allowed (for all xmodem
+* packets except the last header packet) or when non-ACK reply
+* is received during data part transfer.
+*/
rc = kwboot_xm_sendblock(tty, , header && last_block,
-_print, baudrate);
+_print, baudrate, header);
if (rc)
goto out;
 
-- 
2.34.1



[PATCH u-boot-marvell 05/14] tools: kwboot: Do not change received character in kwboot_xm_recv_reply()

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Marvell BootROM expects retransmission of previous xmodem packet only in
the case when it sends NAK response to the host.

Do not change non-xmodem response (possibly UART transfer error) to NAK
in kwboot_xm_recv_reply() function. Allow caller to receive original
response from device.

Change argument 'nak_on_non_xm' to 'stop_on_non_xm'. Instead of changing
non-xmodem character to NAK, stop processing on invalid character and
return it.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 0b97990d09..a619a6c3c1 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -875,7 +875,7 @@ kwboot_baud_magic_handle(int fd, char c, int baudrate)
 }
 
 static int
-kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
+kwboot_xm_recv_reply(int fd, char *c, int stop_on_non_xm,
 int ignore_nak_reply,
 int allow_non_xm, int *non_xm_print,
 int baudrate, int *baud_changed)
@@ -931,10 +931,8 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
*non_xm_print = 1;
}
} else {
-   if (nak_on_non_xm) {
-   *c = NAK;
+   if (stop_on_non_xm)
break;
-   }
timeout = recv_until - _now();
if (timeout < 0) {
errno = ETIMEDOUT;
-- 
2.34.1



[PATCH u-boot-marvell 04/14] tools: kwboot: Remove code for handling CAN byte

2022-01-25 Thread Marek Behún
From: Pali Rohár 

It is unknown why handling of CAN byte was added into kwboot tool as
Marvell BootROM does not support CAN byte. It never sends CAN byte to host
and if host sends CAN byte BootROM handles it as an unknown byte.

Remove code for handling and sending CAN bytes from the kwboot tool.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index be9a751406..0b97990d09 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -63,7 +63,6 @@ static unsigned char kwboot_msg_debug[] = {
 #define EOT4   /* sender end of block transfer */
 #define ACK6   /* target block ack */
 #define NAK21  /* target block negative ack */
-#define CAN24  /* target/sender transfer cancellation */
 
 #define KWBOOT_XM_BLKSZ128 /* xmodem block size */
 
@@ -826,7 +825,7 @@ _now(void)
 static int
 _is_xm_reply(char c)
 {
-   return c == ACK || c == NAK || c == CAN;
+   return c == ACK || c == NAK;
 }
 
 static int
@@ -841,9 +840,6 @@ _xm_reply_to_error(int c)
case NAK:
errno = EBADMSG;
break;
-   case CAN:
-   errno = ECANCELED;
-   break;
default:
errno = EPROTO;
break;
@@ -966,7 +962,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int 
allow_non_xm,
do {
rc = kwboot_tty_send(fd, block, sizeof(*block), 1);
if (rc)
-   return rc;
+   goto err;
 
if (allow_non_xm && !*done_print) {
kwboot_progress(100, '.');
@@ -979,7 +975,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int 
allow_non_xm,
  allow_non_xm, _xm_print,
  baudrate, _changed);
if (rc)
-   goto can;
+   goto err;
 
if (!allow_non_xm && c != ACK)
kwboot_progress(-1, '+');
@@ -990,15 +986,13 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, 
int allow_non_xm,
 
if (allow_non_xm && baudrate && !baud_changed) {
fprintf(stderr, "Baudrate was not changed\n");
-   rc = -1;
errno = EPROTO;
-   goto can;
+   return -1;
}
 
return _xm_reply_to_error(c);
-can:
+err:
err = errno;
-   kwboot_tty_send_char(fd, CAN);
kwboot_printv("\n");
errno = err;
return rc;
-- 
2.34.1



[PATCH u-boot-marvell 03/14] tools: kwboot: Improve retrying logic for incomplete xmodem packets

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Sometimes if the first byte of xmodem packet (SOH) is incorrectly
transmitted, BootROM sends NAK for every non-SOH received byte, which
makes BootROM and the host kwboot tool out of sync. BootROM automatically
re-synchronizes after 2s pause by dropping its input queue. So when
attempting retransmit for 9th time or later, ignore NAK reply from BootROM
and either wait for valid ACK or let kwboot timeout, which implies
re-synchronization.

This fixes retransmission of xmodem packets and allows kwboot to work also
without "Waiting ... and flushing tty" code which is at the beginning of
kwboot xmodem transfer.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1477c0f078..be9a751406 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -880,6 +880,7 @@ kwboot_baud_magic_handle(int fd, char c, int baudrate)
 
 static int
 kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
+int ignore_nak_reply,
 int allow_non_xm, int *non_xm_print,
 int baudrate, int *baud_changed)
 {
@@ -899,8 +900,14 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
}
 
/* If received xmodem reply, end. */
-   if (_is_xm_reply(*c))
+   if (_is_xm_reply(*c)) {
+   if (*c == NAK && ignore_nak_reply) {
+   timeout = recv_until - _now();
+   if (timeout >= 0)
+   continue;
+   }
break;
+   }
 
/*
 * If receiving/printing non-xmodem text output is allowed and
@@ -968,6 +975,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int 
allow_non_xm,
}
 
rc = kwboot_xm_recv_reply(fd, , retries < 3,
+ retries > 8,
  allow_non_xm, _xm_print,
  baudrate, _changed);
if (rc)
@@ -1011,6 +1019,7 @@ kwboot_xm_finish(int fd)
return rc;
 
rc = kwboot_xm_recv_reply(fd, , retries < 3,
+ retries > 8,
  0, NULL, 0, NULL);
if (rc)
return rc;
-- 
2.34.1



[PATCH u-boot-marvell 01/14] tools: kwboot: Increase blk_rsp_timeo to 2s

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Fix xmodem retry mechanism if some bytes from xmodem packet were lost and
BootROM is still waiting for completing previous xmodem packet.

It is required to wait at least 1.312s on A385, otherwise BootROM does not
accept next xmodem packet if previous one was not completely transferred.

2s should be enough timeout cause that BootROM will drop incomplete xmodem
packet and expects new packet.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index c3d8ab6544..82cfd9a827 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -75,7 +75,7 @@ struct kwboot_block {
uint8_t csum;
 } __packed;
 
-#define KWBOOT_BLK_RSP_TIMEO 1000 /* ms */
+#define KWBOOT_BLK_RSP_TIMEO 2000 /* ms */
 #define KWBOOT_HDR_RSP_TIMEO 1 /* ms */
 
 /* ARM code to change baudrate */
-- 
2.34.1



[PATCH u-boot-marvell 02/14] tools: kwboot: Wait blk_rsp_timeo when flushing

2022-01-25 Thread Marek Behún
From: Pali Rohár 

Use the blk_rsp_timeo variable when sleeping before flushing tty.

Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
---
 tools/kwboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 82cfd9a827..1477c0f078 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1081,8 +1081,8 @@ kwboot_xmodem(int tty, const void *_img, size_t size, int 
baudrate)
 */
hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) % KWBOOT_XM_BLKSZ;
 
-   kwboot_printv("Waiting 2s and flushing tty\n");
-   sleep(2); /* flush isn't effective without it */
+   kwboot_printv("Waiting %d ms and flushing tty\n", blk_rsp_timeo);
+   usleep(blk_rsp_timeo * 1000);
tcflush(tty, TCIOFLUSH);
 
pnum = 1;
-- 
2.34.1



[PATCH u-boot-marvell 00/14] Another set of kwboot improvements

2022-01-25 Thread Marek Behún
From: Marek Behún 

Hello Stefan,

here comes another set of kwboot improvements from Pali, reviewed and
signed off by myself.

Marek

Pali Rohár (14):
  tools: kwboot: Increase blk_rsp_timeo to 2s
  tools: kwboot: Wait blk_rsp_timeo when flushing
  tools: kwboot: Improve retrying logic for incomplete xmodem packets
  tools: kwboot: Remove code for handling CAN byte
  tools: kwboot: Do not change received character in
kwboot_xm_recv_reply()
  tools: kwboot: Fix handling of repeated xmodem packets
  tools: kwboot: Show 'E' in progress output when error occurs
  tools: kwboot: Allow to use option -b without image path
  tools: kwboot: Force BootROM to flush input queue after boot pattern
  tools: kwboot: Remove 2s delay before sending first xmodem packet
  tools: kwboot: Handle EINTR in kwboot_write()
  tools: kwboot: Handle EINTR in kwboot_tty_recv()
  tools: kwboot: Fix usage of -D without -t
  tools: kwboot: Set debug flag to 1

 tools/kwboot.c | 154 -
 1 file changed, 115 insertions(+), 39 deletions(-)

-- 
2.34.1



Re: [PATCH 2/4] pci: Extend 'pci regions' command with bus number

2022-01-25 Thread Pali Rohár
On Tuesday 25 January 2022 16:53:05 Stefan Roese wrote:
> On 1/17/22 16:38, Pali Rohár wrote:
> > 'pci regions' currently prints only region information from bus 0 which
> > belongs to controller 0. Parser for 'pci regions' cmdline currently ignores
> > any additional arguments and so U-Boot always uses bus 0.
> > 
> > Regions are stored in controller (not on the bus) and therefore to retrieve
> > controller from the bus, it is needed to call pci_get_controller() which
> > returns root bus. Because bus 0 is root bus, current code worked fine for
> > controller 0.
> > 
> > Extend cmdline parser for 'pci regions' to allows specifying bus number,
> > extend pci_show_regions() code to accept also non-zero bus number and
> > print bus ranges for which is regions configuration assigned.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Nitpicking comment below. But still:
> 
> Reviewed-by: Stefan Roese 
> 
> Thanks,
> Stefan
> 
> > ---
> >   cmd/pci.c | 10 ++
> >   1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/cmd/pci.c b/cmd/pci.c
> > index 3b1863f139c9..53edf0d90010 100644
> > --- a/cmd/pci.c
> > +++ b/cmd/pci.c
> > @@ -443,7 +443,7 @@ static const struct pci_flag_info {
> >   static void pci_show_regions(struct udevice *bus)
> >   {
> > -   struct pci_controller *hose = dev_get_uclass_priv(bus);
> > +   struct pci_controller *hose = 
> > dev_get_uclass_priv(pci_get_controller(bus));
> > const struct pci_region *reg;
> > int i, j;
> > @@ -452,6 +452,7 @@ static void pci_show_regions(struct udevice *bus)
> > return;
> > }
> > +   printf("Buses %02x-%02x\n", hose->first_busno, hose->last_busno);
> > printf("#   %-18s %-18s %-18s  %s\n", "Bus start", "Phys start", "Size",
> >"Flags");
> > for (i = 0, reg = hose->regions; i < hose->region_count; i++, reg++) {
> > @@ -520,8 +521,9 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
> > argc, char *const argv[])
> > value = 0;
> > argc--;
> > }
> > -   if (argc > 1)
> > -   busnum = hextoul(argv[1], NULL);
> > +   if (argc > 2 || (argc > 1 && cmd != 'r' && argv[1][0] 
> > != 's')) {
> > +   busnum = hextoul(argv[argc - 1], NULL);
> > +   }
> 
> Nitpicking:
> Single line statements without parentheses is preferred.

In next patches I'm adding more statements into this branch and I did
not wanted to make next patches too noisy.

> > }
> > ret = uclass_get_device_by_seq(UCLASS_PCI, busnum, );
> > if (ret) {
> > @@ -586,7 +588,7 @@ static char pci_help_text[] =
> > "- show header of PCI device 'bus.device.function'\n"
> > "pci bar b.d.f\n"
> > "- show BARs base and size for device b.d.f'\n"
> > -   "pci regions\n"
> > +   "pci regions [bus]\n"
> > "- show PCI regions\n"
> > "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n"
> > "- display PCI configuration space (CFG)\n"
> 
> Viele Grüße,
> Stefan Roese
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Compile only changed files when doing 'make'?

2022-01-25 Thread Grant Edwards
I'm working on a Renesas supplied port of U-Boot, and it seems that
'make' always compiles every single (configured) source file instead
compiling only the source files that have been changed since the
previous 'make'.  I've never run into this before on projects that use
'make', and it makes development of U-Boot rather grueling.

Is that due to something Renesas broke?

Or is that a "feature" of the standard U-Boot Makefile?

--
Grant





Re: [PATCH u-boot-pci] pci: iproc: Set all 24 bits of PCI class code

2022-01-25 Thread Tom Rini
On Wed, Jan 05, 2022 at 10:50:20AM +0100, Pali Rohár wrote:

> Register 0x43c in its low 24 bits contains PCI class code.
> 
> Update code to set all 24 bits of PCI class code and not only upper 16 bits
> of PCI class code.
> 
> Use standard U-Boot macro (PCI_CLASS_BRIDGE_PCI << 8) for constructing all
> 24-bits of PCI class for PCI bridge Normal decode.
> 
> Signed-off-by: Pali Rohár 
> Acked-by: Roman Bacik 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 6/6] moveconfig: Fix some pylint errors

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:35PM -0700, Simon Glass wrote:

> There are over 200 errors in this file. Fix some of them, starting at the
> beginning of the file. Future work can continue this effort.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/6] moveconfig: Use a function to read files

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:34PM -0700, Simon Glass wrote:

> At present there is quite a bit of ad-hoc code reading from files. The
> most common case is to read the file as lines. Put it in a function and
> set the unicode encoding correctly.
> 
> Avoid writing back to a file when there are obviously no changes as this
> speeds things up slightly.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/6] moveconfig: Use a function to write files

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:33PM -0700, Simon Glass wrote:

> At present there is quite a bit of ad-hoc code writing to files. The
> treatment of newlines is different in some of them. Put it in a function
> and set the unicode encoding correctly.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/6] moveconfig: Drop check for old Python

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:32PM -0700, Simon Glass wrote:

> Python 2 is not supported anymore and Python 3 has had subprocess.DEVNULL
> since version 3.3 which was released in 2012. Drop the unnecessary check.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/6] moveconfig: Convert to ArgumentParser

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:31PM -0700, Simon Glass wrote:

> This is a newer library and is now preferred for Python scripts. Update
> the code to use it instead of optparse
> 
> Use 'args' instead of 'options' throughout, since this is the term used
> in that module. Also it helps to avoid confusion with CONFIG options, a
> term that is used in this file.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/6] moveconfig: Use single quotes

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 02:54:30PM -0700, Simon Glass wrote:

> Quite a few places use double quotes. Fix this to be consistent with
> other Python code in U-Boot.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/5] moveconfig: Allow querying board configuration

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 08:09:46AM -0700, Simon Glass wrote:

> It is useful to be able to find out which boards define a particular
> option, or combination of options. This is not as easy as grepping the
> defconfig files since many options are implied by others.
> 
> Add a -f option to the moveconfig tool to permit this. Update the
> documentation to cover this, including a better title for the doc page.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/5] moveconfig: Allow adding unit tests

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 08:09:45AM -0700, Simon Glass wrote:

> Add a -t option to run unit tests in this program. So far, there is none.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/5] moveconfig: Sort the options

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 08:09:44AM -0700, Simon Glass wrote:

> Put the options in sorted order by their short name so it is easier to
> find an option.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/5] moveconfig: Read the database in a separate function

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 08:09:43AM -0700, Simon Glass wrote:

> Move this code out into a function so it can be used elsewhere.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/5] moveconfig: Correct operation of the 'imply' feature

2022-01-25 Thread Tom Rini
On Sat, Dec 18, 2021 at 08:09:42AM -0700, Simon Glass wrote:

> This doesn't work anymore, since the Kconfig update. The script has no
> tests so we did not notice. Fix it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] test: fix pylint warnings in test_env.py

2022-01-25 Thread Tom Rini
On Fri, Nov 26, 2021 at 11:30:27PM +0100, Heinrich Schuchardt wrote:

> * assert does not need parentheses
> * add module docstring
> * fix misspelled constant True
> * limit lines to 100 characters
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/6] Makefile: Add a pylint checker to the build

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:40PM -0700, Simon Glass wrote:

> At present the Python code in U-Boot is somewhat inconsistent, with some
> files passing pylint quite cleanly and others not.
> 
> Add a way to track progress on this clean-up, by checking that no module
> has got any worse as a result of changes.
> 
> This can be used with 'make pylint'.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/6] tools: Add init files for Python tools

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:39PM -0700, Simon Glass wrote:

> Add some empty __init__ files for binman, buildman and dtoc so that
> pylint is able to recognise these as Python modules and produce more
> useful pylint output.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/6] patman: Update the list of modules

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:38PM -0700, Simon Glass wrote:

> Update the __init__ file to include recently added files.
> 
> Add a license header while we are here.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/6] dtoc: Fix up a code comment that confuses pylint

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:37PM -0700, Simon Glass wrote:

> This produces a pylint error at present. Fix it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/6] .gitignore: Ignore any html coverage directory

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:36PM -0700, Simon Glass wrote:

> This is created when checking code coverage of Python tools. Ignore it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/6] Makefile: Add a pylint checker to the build

2022-01-25 Thread Tom Rini
On Sun, Nov 21, 2021 at 08:48:40PM -0700, Simon Glass wrote:

> At present the Python code in U-Boot is somewhat inconsistent, with some
> files passing pylint quite cleanly and others not.
> 
> Add a way to track progress on this clean-up, by checking that no module
> has got any worse as a result of changes.
> 
> This can be used with 'make pylint'.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  .gitignore|   4 +
>  Makefile  |  45 +++-
>  doc/develop/index.rst |   8 ++
>  doc/develop/python_cq.rst |  80 +++
>  scripts/pylint.base   | 211 ++
>  5 files changed, 347 insertions(+), 1 deletion(-)
>  create mode 100644 doc/develop/python_cq.rst
>  create mode 100644 scripts/pylint.base

So, I'm applying this momentarily.  But given the discussion at the
time, I wanted to follow up as well with some commentary.  The scoring
mechanism is not perfect and I'm not applying the final part of this to
enable CI yet.  In terms of minimum score?  I don't know how that would
work, setting aside problems like removing code leads to a possibly
worse ratio.  Maybe we need to get some people listed under MAINTAINERS
for python code?  I'll be putting pylint in my local testing loop and
that'll at least make me question regressions but arbitrarily taking
"binman.fdt_test 3.23" I can't see what on earth is even related to that
score since there's nothing useful to me under "git grep fdt_test
tools/".  But overall I think this at least starts us down the right
track of making it easier to make our python code more generally python
compliant.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/4] pci: Extend 'pci' command with bus option '*'

2022-01-25 Thread Stefan Roese

On 1/17/22 16:38, Pali Rohár wrote:

Allow to call 'pci' and 'pci regions' commands with bus option '*' which
cause pci to process all buses.

PCIe is point-to-point HW and so on each bus is maximally one physical
device. Therefore for PCIe it is common to have multiple buses.

This change allows to easily print all available PCIe devices in system.

Make '*' as default option when no bus argument is specified.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/pci.c | 45 +++--
  1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/cmd/pci.c b/cmd/pci.c
index 8d2c0c4b43dd..4415feb2225b 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -256,10 +256,8 @@ static void pci_header_show(struct udevice *dev)
  }
  }
  
-static void pciinfo_header(int busnum, bool short_listing)

+static void pciinfo_header(bool short_listing)
  {
-   printf("Scanning PCI devices on bus %d\n", busnum);
-
if (short_listing) {
printf("BusDevFun  VendorId   DeviceId   Device Class   
Sub-Class\n");

printf("_\n");
@@ -288,11 +286,15 @@ static void pci_header_show_brief(struct udevice *dev)
   pci_class_str(class), subclass);
  }
  
-static void pciinfo(struct udevice *bus, bool short_listing)

+static void pciinfo(struct udevice *bus, bool short_listing, bool multi)
  {
struct udevice *dev;
  
-	pciinfo_header(dev_seq(bus), short_listing);

+   if (!multi)
+   printf("Scanning PCI devices on bus %d\n", dev_seq(bus));
+
+   if (!multi || dev_seq(bus) == 0)
+   pciinfo_header(short_listing);
  
  	for (device_find_first_child(bus, );

 dev;
@@ -483,10 +485,11 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
ulong addr = 0, value = 0, cmd_size = 0;
enum pci_size_t size = PCI_SIZE_32;
struct udevice *dev, *bus;
-   int busnum = 0;
+   int busnum = -1;
pci_dev_t bdf = 0;
char cmd = 's';
int ret = 0;
+   char *endp;
  
  	if (argc > 1)

cmd = argv[1][0];
@@ -522,7 +525,11 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
argc--;
}
if (argc > 2 || (argc > 1 && cmd != 'r' && argv[1][0] 
!= 's')) {
-   busnum = hextoul(argv[argc - 1], NULL);
+   if (argv[argc - 1][0] != '*') {
+   busnum = hextoul(argv[argc - 1], );
+   if (*endp)
+   goto usage;
+   }
argc--;
}
if (cmd == 'r' && argc > 2)
@@ -530,6 +537,24 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
else if (cmd != 'r' && (argc > 2 || (argc == 2 && 
argv[1][0] != 's')))
goto usage;
}
+   if (busnum == -1) {
+   if (cmd != 'r') {
+   for (busnum = 0;
+uclass_get_device_by_seq(UCLASS_PCI, busnum, 
) == 0;
+busnum++)
+   pciinfo(bus, value, true);
+   } else {
+   for (busnum = 0;
+uclass_get_device_by_seq(UCLASS_PCI, busnum, 
) == 0;
+busnum++) {
+   /* Regions are controller specific so 
skip non-root buses */
+   if (device_is_on_pci_bus(bus))
+   continue;
+   pci_show_regions(bus);
+   }
+   }
+   return 0;
+   }
ret = uclass_get_device_by_seq(UCLASS_PCI, busnum, );
if (ret) {
printf("No such bus\n");
@@ -538,7 +563,7 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
if (cmd == 'r')
pci_show_regions(bus);
else
-   pciinfo(bus, value);
+   pciinfo(bus, value, false);
return 0;
}
  
@@ -585,7 +610,7 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
  
  #ifdef CONFIG_SYS_LONGHELP

  static char pci_help_text[] =
-   "[bus] [long]\n"
+   "[bus|*] [long]\n"
"- short or long list of PCI devices on bus 'bus'\n"
"pci enum\n"
"- Enumerate PCI buses\n"

Re: [PATCH 3/4] pci: Add checks for valid cmdline arguments

2022-01-25 Thread Stefan Roese

On 1/17/22 16:38, Pali Rohár wrote:

Currently pci command ignores invalid cmdline arguments and do something.
Add checks that all passed arguments were processed.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/pci.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/cmd/pci.c b/cmd/pci.c
index 53edf0d90010..8d2c0c4b43dd 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -523,7 +523,12 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
}
if (argc > 2 || (argc > 1 && cmd != 'r' && argv[1][0] 
!= 's')) {
busnum = hextoul(argv[argc - 1], NULL);
+   argc--;
}
+   if (cmd == 'r' && argc > 2)
+   goto usage;
+   else if (cmd != 'r' && (argc > 2 || (argc == 2 && 
argv[1][0] != 's')))
+   goto usage;
}
ret = uclass_get_device_by_seq(UCLASS_PCI, busnum, );
if (ret) {


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH 2/4] pci: Extend 'pci regions' command with bus number

2022-01-25 Thread Stefan Roese

On 1/17/22 16:38, Pali Rohár wrote:

'pci regions' currently prints only region information from bus 0 which
belongs to controller 0. Parser for 'pci regions' cmdline currently ignores
any additional arguments and so U-Boot always uses bus 0.

Regions are stored in controller (not on the bus) and therefore to retrieve
controller from the bus, it is needed to call pci_get_controller() which
returns root bus. Because bus 0 is root bus, current code worked fine for
controller 0.

Extend cmdline parser for 'pci regions' to allows specifying bus number,
extend pci_show_regions() code to accept also non-zero bus number and
print bus ranges for which is regions configuration assigned.

Signed-off-by: Pali Rohár 


Nitpicking comment below. But still:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  cmd/pci.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/cmd/pci.c b/cmd/pci.c
index 3b1863f139c9..53edf0d90010 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -443,7 +443,7 @@ static const struct pci_flag_info {
  
  static void pci_show_regions(struct udevice *bus)

  {
-   struct pci_controller *hose = dev_get_uclass_priv(bus);
+   struct pci_controller *hose = 
dev_get_uclass_priv(pci_get_controller(bus));
const struct pci_region *reg;
int i, j;
  
@@ -452,6 +452,7 @@ static void pci_show_regions(struct udevice *bus)

return;
}
  
+	printf("Buses %02x-%02x\n", hose->first_busno, hose->last_busno);

printf("#   %-18s %-18s %-18s  %s\n", "Bus start", "Phys start", "Size",
   "Flags");
for (i = 0, reg = hose->regions; i < hose->region_count; i++, reg++) {
@@ -520,8 +521,9 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
value = 0;
argc--;
}
-   if (argc > 1)
-   busnum = hextoul(argv[1], NULL);
+   if (argc > 2 || (argc > 1 && cmd != 'r' && argv[1][0] 
!= 's')) {
+   busnum = hextoul(argv[argc - 1], NULL);
+   }


Nitpicking:
Single line statements without parentheses is preferred.


}
ret = uclass_get_device_by_seq(UCLASS_PCI, busnum, );
if (ret) {
@@ -586,7 +588,7 @@ static char pci_help_text[] =
"- show header of PCI device 'bus.device.function'\n"
"pci bar b.d.f\n"
"- show BARs base and size for device b.d.f'\n"
-   "pci regions\n"
+   "pci regions [bus]\n"
"- show PCI regions\n"
"pci display[.b, .w, .l] b.d.f [address] [# of objects]\n"
"- display PCI configuration space (CFG)\n"


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH 1/4] pci: Fix setting controller's last_busno

2022-01-25 Thread Stefan Roese

On 1/17/22 16:38, Pali Rohár wrote:

Initially it is set to dev_seq but update to the last bus number is
missing. Fix it.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/pci/pci-uclass.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 8c4d75bdb685..374b22601818 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -562,6 +562,8 @@ int pci_auto_config_devices(struct udevice *bus)
if (pplat->class == (PCI_CLASS_DISPLAY_VGA << 8))
set_vga_bridge_bits(dev);
}
+   if (hose->last_busno < sub_bus)
+   hose->last_busno = sub_bus;
debug("%s: done\n", __func__);
  
  	return log_msg_ret("sub", sub_bus);


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH] arm: kirkwood: Pogoplug V4 : Use Marvel network PHY driver

2022-01-25 Thread Stefan Roese

On 1/25/22 10:48, Tony Dinh wrote:

The Pogoplug V4 board has the network chip Marvell 88E1118R. So to
properly configure the network, enable CONFIG_PHY_MARVELL to activate
the driver M88E1118R.

- This patch depends on the series:
https://patchwork.ozlabs.org/project/uboot/patch/20220124061712.28316-2-mibo...@gmail.com/

Signed-off-by: Tony Dinh 


I was wondering, how all this "magically" works without the Marvell PHY
driver being involved. ;) So:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

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

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index 5490067b9e..1cf409c834 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -62,6 +62,7 @@ CONFIG_KIRKWOOD_GPIO=y
  CONFIG_MVEBU_MMC=y
  CONFIG_MTD=y
  CONFIG_MTD_RAW_NAND=y
+CONFIG_PHY_MARVELL=y
  CONFIG_DM_ETH=y
  CONFIG_MVGBE=y
  CONFIG_MII=y


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH 2/5] sunxi: move Cortex SMPEN setting into start.S

2022-01-25 Thread Andre Przywara
On Mon, 24 Jan 2022 20:47:30 -0600
Samuel Holland  wrote:

Hi Samuel,

many thanks for having a look!

> On 1/24/22 7:15 PM, Andre Przywara wrote:
> > According to their TRMs, Cortex ARMv7 CPUs with SMP support require the
> > ACTLR.SMPEN bit to be set as early as possible, before any cache or TLB
> > maintenance operations are done. As we do those things still in start.S,
> > we need to move the SMPEN bit setting there, too.
> > 
> > This introduces a new ARMv7 wide symbol and code to set bit 6 in ACTLR
> > very early in start.S, and moves sunxi boards over to use that instead
> > of the custom code we had in our board.c file (where it was called
> > technically too late).
> > 
> > In practice we got away with this so far, because at this point all the
> > other cores were still in reset, so any broadcasting would have been
> > ignored anyway. But it is architecturally cleaner to do it early, and
> > we move a core specific piece of code out of board.c.
> > 
> > This also gets rid of the ARM_CORTEX_CPU_IS_UP kludge I introduced a few
> > years back, and moves the respective logic into the new Kconfig entry.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  arch/arm/Kconfig|  3 ---
> >  arch/arm/cpu/armv7/Kconfig  |  7 +++
> >  arch/arm/cpu/armv7/start.S  | 11 +++
> >  arch/arm/mach-sunxi/Kconfig |  2 --
> >  arch/arm/mach-sunxi/board.c |  9 -
> >  5 files changed, 18 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 6b11c3a50d9..7893d74fab2 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -452,9 +452,6 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
> >   values, then choose this option, and create a file included as
> >which contains the required assembler code.
> >  
> > -config ARM_CORTEX_CPU_IS_UP
> > -   bool
> > -
> >  config USE_ARCH_MEMCPY
> > bool "Use an assembly optimized implementation of memcpy"
> > default y if !ARM64
> > diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
> > index 60bb0a9e1ec..85e5229a060 100644
> > --- a/arch/arm/cpu/armv7/Kconfig
> > +++ b/arch/arm/cpu/armv7/Kconfig
> > @@ -76,4 +76,11 @@ config ARMV7_LPAE
> > Say Y here to use the long descriptor page table format. This is
> > required if U-Boot runs in HYP mode.
> >  
> > +config ARMV7_SET_CORTEX_SMPEN
> > +   bool "Enable ACTLR.SMP bit"
> > +   default n if MACH_SUN4I || MACH_SUN5I
> > +   default y if ARCH_SUNXI && !ARM64  
> 
> If this is required by the CPU, why is it shown to the user? Shouldn't it be
> selected by MACH_SUN6/7/8/9I? That is what I see platforms doing with
> ARMV8_SET_SMPEN.

You are right, it shouldn't be user visible, instead selected by platform
Kconfigs. Technically we could even work that out at runtime (read MIDR &
MPIDR), but I think there are situations were we want to avoid this, so we
would probably need an opt-in from the platform anyways.
This patch was just trying to mimic the existing logic as close as
possible, since we know that works for years. Changing this is scary
enough. And the negative logic is shorter than enumerating all ARMv7 SMP
cores, the list of which could even grow.

But indeed there is more cleanup potential here. I see some platforms
setting this bit in their code (similar to what sunxi did), but I didn't
dare to touch those. Maybe I add a follow up patch to move those platforms
over, and possibly merge this with ARMV8_SET_SMPEN on the way.

Cheers,
Andre

> > +   help
> > + Enable the ARM Cortex ACTLR.SMP enable bit on startup.
> > +
> >  endif
> > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> > index 698e15b8e18..af87a5432ae 100644
> > --- a/arch/arm/cpu/armv7/start.S
> > +++ b/arch/arm/cpu/armv7/start.S
> > @@ -173,6 +173,17 @@ ENDPROC(switch_to_hypervisor)
> >   *
> >   */
> >  ENTRY(cpu_init_cp15)
> > +
> > +#if CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN)
> > +   /*
> > +* The Arm Cortex-A7 TRM says this bit must be enabled before
> > +* "any cache or TLB maintenance operations are performed".
> > +*/
> > +   mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
> > +   orr r0, r0, #1 << 6 @ set SMP bit to enable coherency
> > +   mcr p15, 0, r0, c1, c0, 1   @ write auxilary control register
> > +#endif
> > +
> > /*
> >  * Invalidate L1 I/D
> >  */
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 2c18cf02d1a..4e49ad4f0c0 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -186,7 +186,6 @@ choice
> >  config MACH_SUN4I
> > bool "sun4i (Allwinner A10)"
> > select CPU_V7A
> > -   select ARM_CORTEX_CPU_IS_UP
> > select PHY_SUN4I_USB
> > select DRAM_SUN4I
> > select SUNXI_GEN_SUN4I
> > @@ -197,7 +196,6 @@ config MACH_SUN4I
> >  config MACH_SUN5I
> > bool "sun5i (Allwinner A13)"
> > 

Re: [PATCH v3 00/20] J721S2: Add initial support

2022-01-25 Thread Aswath Govindraju
Hi All,

On 18/01/22 12:57 pm, Aswath Govindraju wrote:
> The J721S2 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration in automotive ADAS applications and
> industrial applications requiring AI at the network edge. This SoC extends
> the Jacinto 7 family of SoCs with focus on lowering system costs and power
> while providing interfaces, memory architecture and compute performance for
> single and multi-sensor applications.
> 
> Some highlights of this SoC are:
> 
> * Dual Cortex-A72s in a single cluster, three clusters of lockstep capable
> dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x
> floating point Vector DSP.
> * 3D GPU: Automotive grade IMG BXS-4-64
> * Vision Processing Accelerator (VPAC) with image signal processor and
> Depth and Motion Processing Accelerator (DMPAC)
> * Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface.
> * Two Ethernet ports with RGMII support.
> * Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems,
> * Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller,
> QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
> * Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL
> management.
> * Chips and Media Wave521CL H.264/H.265 encode/decode engine
> 
> See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021)
> for further details: http://www.ti.com/lit/pdf/spruj28
> 
> bootlog:
>  - https://pastebin.ubuntu.com/p/8FfVJjVVSC/
> 
> Notes:
> - Patches 12, 13, 14, 15 and 16 are synced from upstream kernel v5.17-rc1
>   tag
> 

I have posted v4 for this series after addressing the comments in this
series.

Thanks,
Aswath

> Changes since v2:
> - Removed the redundant config K3_J721S2_DDRSS and instead used
> K3_J721E_DDRSS
> - Formatted the Kconfig files to remove extra lines
> - Added dts files in the MAINTAINERS baord folder
> 
> Changes since v1:
> - Removed unused serial aliases
> - Assigned serial2 alias for main uart8 instance
> - Moved aliases to respective board files
> 
> Aswath Govindraju (10):
>   ram: k3-ddrss: lpddr4_structs_if.h: Add a pointer to ddr instance
>   ram: k3-ddrss: Add support for multiple instances of DDR subsystems
>   ram: k3-ddrss: Add support for configuring MSMC subsystem in case of
> Multiple DDR subsystems
>   dt-bindings: ti-serdes-mux: Add defines for J721S2 SoC
>   dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2
>   arm: dts: Add initial support for J721S2 SoC
>   arm: dts: Add initial support for J721S2 System on Module
>   arm: dts: Add support for A72 specific J721S2 Common Processor Board
>   arm: dts: k3-j721s2: Add r5 specific dt support
>   arm: dts: k3-j721s2-ddr: Add DDR support
> 
> David Huang (9):
>   arm: K3: Add basic support for J721S2 SoC definition
>   drivers: dma: Add support for J721S2
>   clk: clk-k3: Add support for J721S2 SoC
>   power: domain: ti: Add support for J721S2 SoC
>   ram: k3-ddrss: Add support for J721S2 SoC
>   soc: ti: k3-socinfo: Add entry for J721S2 SoC
>   board: ti: j721s2: Add board support for J721S2
>   configs: j721s2_evm_r5_defconfig: Add R5 SPL specific defconfig
>   configs: j721s2_evm_a72_defconfig: Add A72 specific defconfig
> 
> Nishanth Menon (1):
>   remoteproc: k3_system_controller: Support optional boot_notification
> channel
> 
>  arch/arm/dts/Makefile |2 +
>  .../k3-j721s2-common-proc-board-u-boot.dtsi   |  149 +
>  arch/arm/dts/k3-j721s2-common-proc-board.dts  |  430 ++
>  arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi  | 4387 
>  arch/arm/dts/k3-j721s2-ddr.dtsi   | 4440 +
>  arch/arm/dts/k3-j721s2-main.dtsi  |  937 
>  arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi|  302 ++
>  .../dts/k3-j721s2-r5-common-proc-board.dts|  198 +
>  arch/arm/dts/k3-j721s2-som-p0.dtsi|  173 +
>  arch/arm/dts/k3-j721s2.dtsi   |  167 +
>  arch/arm/mach-k3/Kconfig  |   15 +-
>  arch/arm/mach-k3/Makefile |1 +
>  arch/arm/mach-k3/arm64-mmu.c  |   53 +
>  arch/arm/mach-k3/include/mach/hardware.h  |4 +
>  .../mach-k3/include/mach/j721s2_hardware.h|   60 +
>  arch/arm/mach-k3/include/mach/j721s2_spl.h|   46 +
>  arch/arm/mach-k3/include/mach/spl.h   |4 +
>  arch/arm/mach-k3/j721s2/Makefile  |5 +
>  arch/arm/mach-k3/j721s2/clk-data.c|  403 ++
>  arch/arm/mach-k3/j721s2/dev-data.c|   85 +
>  arch/arm/mach-k3/j721s2_init.c|  312 ++
>  board/ti/j721s2/Kconfig   |   63 +
>  board/ti/j721s2/MAINTAINERS   |   16 +
>  board/ti/j721s2/Makefile  |8 +
>  board/ti/j721s2/evm.c |  180 +
>  configs/j721s2_evm_a72_defconfig  |  207 +
>  configs/j721s2_evm_r5_defconfig   |  171 +
>  

[PATCH v4 20/20] configs: j721s2_evm_a72_defconfig: Add A72 specific defconfig

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Enable A72 specific configs for J721S2

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Hari Nagalla 
---
 configs/j721s2_evm_a72_defconfig | 207 +++
 1 file changed, 207 insertions(+)
 create mode 100644 configs/j721s2_evm_a72_defconfig

diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
new file mode 100644
index ..92f668f8f931
--- /dev/null
+++ b/configs/j721s2_evm_a72_defconfig
@@ -0,0 +1,207 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_J721S2=y
+CONFIG_TARGET_J721S2_A72_EVM=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
+CONFIG_SYS_MALLOC_LEN=0x200
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_ENV_OFFSET_REDUND=0x6A
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721s2-common-proc-board"
+CONFIG_DISTRO_DEFAULTS=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run 
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_LOGLEVEL=7
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_I2C=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_NOR_SUPPORT=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_THERMAL=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_REMOTEPROC=y
+CONFIG_CMD_UFS=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0,nor0=47034000.hyperbus"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=4704.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.phypattern);47034000.hyperbus:512k(hbmc.tiboot3),2m(hbmc.tispl),4m(hbmc.u-boot),256k(hbmc.env),-@8m(hbmc.rootfs)"
+CONFIG_CMD_UBI=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x4
+CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
+CONFIG_CLK_CCF=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_CFI_FLASH=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HS512T=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
+# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_MTD=y

[PATCH v4 19/20] configs: j721s2_evm_r5_defconfig: Add R5 SPL specific defconfig

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Enable R5 SPL specific configs for J721S2.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Hari Nagalla 
---
 configs/j721s2_evm_r5_defconfig | 171 
 1 file changed, 171 insertions(+)
 create mode 100644 configs/j721s2_evm_r5_defconfig

diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig
new file mode 100644
index ..4ecab605357c
--- /dev/null
+++ b/configs/j721s2_evm_r5_defconfig
@@ -0,0 +1,171 @@
+CONFIG_PANIC_HANG=y
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x1
+CONFIG_SOC_K3_J721S2=y
+CONFIG_K3_EARLY_CONS=y
+CONFIG_TARGET_J721S2_R5_EVM=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_SPL_TEXT_BASE=0x41c0
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721s2-r5-common-proc-board"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
+CONFIG_USE_BOOTCOMMAND=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_FS_EXT4=y
+CONFIG_SPL_I2C=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_NOR_SUPPORT=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_THERMAL=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_DFU=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x4
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+# CONFIG_CLK_TI_SCI is not set
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_FS_LOADER=y
+CONFIG_DM_MMC=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_CFI_FLASH=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HS512T=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+# CONFIG_TI_SCI_POWER_DOMAIN is not set
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_CADENCE_QSPI_PHY=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_DM_THERMAL=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_USB_CDNS3=y
+CONFIG_USB_CDNS3_GADGET=y
+CONFIG_SPL_USB_CDNS3_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0x6168
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_FS_EXT4=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_K3_DM_FW=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_LIBFDT=y
+CONFIG_SPL_DM_GPIO=y
+CONFIG_SYS_MALLOC_LEN=0x200
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_SIZE_LIMIT=0x8

[PATCH v4 17/20] arm: dts: k3-j721s2: Add r5 specific dt support

2022-01-25 Thread Aswath Govindraju
Add initial support for device tree that runs on R5.

Signed-off-by: Aswath Govindraju 
---
 arch/arm/dts/Makefile |   3 +-
 .../dts/k3-j721s2-r5-common-proc-board.dts| 196 ++
 2 files changed, 198 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-j721s2-r5-common-proc-board.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 84cf3d76ffe7..825a5be588e0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1132,7 +1132,8 @@ dtb-$(CONFIG_SOC_K3_J721E) += 
k3-j721e-common-proc-board.dtb \
  k3-j721e-r5-common-proc-board.dtb \
  k3-j7200-common-proc-board.dtb \
  k3-j7200-r5-common-proc-board.dtb
-dtb-$(CONFIG_SOC_K3_J721S2) += k3-j721s2-common-proc-board.dtb
+dtb-$(CONFIG_SOC_K3_J721S2) += k3-j721s2-common-proc-board.dtb\
+  k3-j721s2-r5-common-proc-board.dtb
 dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
  k3-am642-r5-evm.dtb \
  k3-am642-sk.dtb \
diff --git a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts 
b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
new file mode 100644
index ..12590d391fce
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721s2-som-p0.dtsi"
+
+/ {
+   chosen {
+   firmware-loader = _loader0;
+   stdout-path = _uart8;
+   tick-timer = 
+   };
+
+   aliases {
+   remoteproc0 = 
+   remoteproc1 = _0;
+   };
+
+   fs_loader0: fs_loader@0 {
+   compatible = "u-boot,fs-loader";
+   u-boot,dm-pre-reloc;
+   };
+
+   a72_0: a72@0 {
+   compatible = "ti,am654-rproc";
+   reg = <0x0 0x00a9 0x0 0x10>;
+   power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+   <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+   resets = <_reset 202 0>;
+   clocks = <_clks 61 1>;
+   assigned-clocks = <_clks 61 1>, <_clks 202 0>;
+   assigned-clock-parents = <_clks 61 2>;
+   assigned-clock-rates = <2>, <20>;
+   ti,sci = <>;
+   ti,sci-proc-id = <32>;
+   ti,sci-host-id = <10>;
+   u-boot,dm-spl;
+   };
+
+   clk_200mhz: dummy_clock_200mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   u-boot,dm-spl;
+   };
+
+   clk_19_2mhz: dummy_clock_19_2mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   u-boot,dm-spl;
+   };
+};
+
+_mcu_wakeup {
+   sa3_secproxy: secproxy@4488 {
+   u-boot,dm-spl;
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x0 0x4488 0x0 0x2>,
+ <0x0 0x4486 0x0 0x2>,
+ <0x0 0x4360 0x0 0x1>;
+   reg-names = "rt", "scfg", "target_data";
+   #mbox-cells = <1>;
+   };
+
+   mcu_secproxy: secproxy@2a38 {
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x0 0x2a38 0x0 0x8>,
+ <0x0 0x2a40 0x0 0x8>,
+ <0x0 0x2a48 0x0 0x8>;
+   reg-names = "rt", "scfg", "target_data";
+   #mbox-cells = <1>;
+   u-boot,dm-spl;
+   };
+
+   sysctrler: sysctrler {
+   compatible = "ti,am654-system-controller";
+   mboxes= <_secproxy 4>, <_secproxy 5>, <_secproxy 5>;
+   mbox-names = "tx", "rx", "boot_notify";
+   u-boot,dm-spl;
+   };
+
+   dm_tifs: dm-tifs {
+   compatible = "ti,j721e-dm-sci";
+   ti,host-id = <3>;
+   ti,secure-host;
+   mbox-names = "rx", "tx";
+   mboxes= <_secproxy 21>,
+   <_secproxy 23>;
+   u-boot,dm-spl;
+   };
+};
+
+_pmx0 {
+   main_uart8_pins_default: main-uart8-pins-default {
+   pinctrl-single,pins = <
+   J721S2_IOPAD(0x040, PIN_INPUT, 14) /* (AC28) 
MCASP0_AXR0.UART8_CTSn */
+   J721S2_IOPAD(0x044, PIN_OUTPUT, 14) /* (Y26) 
MCASP0_AXR1.UART8_RTSn */
+   J721S2_IOPAD(0x0d0, PIN_INPUT, 11) /* (AF26) 
SPI0_CS1.UART8_RXD */
+   J721S2_IOPAD(0x0d4, PIN_OUTPUT, 11) /* (AH27) 
SPI0_CLK.UART8_TXD */
+   >;
+   };
+
+   main_mmc1_pins_default: main-mmc1-pins-default {
+   pinctrl-single,pins = <
+  

[PATCH v4 16/20] arm: dts: Add support for A72 specific J721S2 Common Processor Board

2022-01-25 Thread Aswath Govindraju
The EVM architecture for J721S2 is similar to that of J721E and J7200. It
is as follows,

+--+
|   +---+  |
|   |   |  |
|   |Add-on Card 1 Options  |  |
|   |   |  |
|   +---+  |
|  |
|  |
| +---+|
| |   ||
| |   SOM ||
|  +--+   |   ||
|  |  |   |   ||
|  |  Add-on  |   +---+|
|  |  Card 2  ||Power Supply
|  |  Options |||
|  |  |||
|  +--+| <---
+--+
 Common Processor Board

Common Processor board is the baseboard that contains most of the actual
connectors, power supply etc. The System on Module (SoM) is plugged on to
the common processor baord. Therefore, add support for peripherals brought
out in the common processor board.

Link to Common Processor Board: https://www.ti.com/lit/zip/sprr439

Signed-off-by: Aswath Govindraju 
---
 arch/arm/dts/Makefile |   1 +
 .../k3-j721s2-common-proc-board-u-boot.dtsi   | 149 ++
 arch/arm/dts/k3-j721s2-common-proc-board.dts  | 430 ++
 3 files changed, 580 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-j721s2-common-proc-board.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ce332021d895..84cf3d76ffe7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1132,6 +1132,7 @@ dtb-$(CONFIG_SOC_K3_J721E) += 
k3-j721e-common-proc-board.dtb \
  k3-j721e-r5-common-proc-board.dtb \
  k3-j7200-common-proc-board.dtb \
  k3-j7200-r5-common-proc-board.dtb
+dtb-$(CONFIG_SOC_K3_J721S2) += k3-j721s2-common-proc-board.dtb
 dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
  k3-am642-r5-evm.dtb \
  k3-am642-sk.dtb \
diff --git a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
new file mode 100644
index ..749bc717f390
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+   chosen {
+   stdout-path = "serial2:115200n8";
+   tick-timer = 
+   };
+
+   aliases {
+   serial0 = _uart0;
+   serial1 = _uart0;
+   serial2 = _uart8;
+   i2c0 = _i2c0;
+   i2c1 = _i2c0;
+   i2c2 = _i2c1;
+   i2c3 = _i2c0;
+   ethernet0 = _port1;
+   };
+};
+
+_i2c0 {
+   u-boot,dm-spl;
+};
+
+_main {
+   u-boot,dm-spl;
+};
+
+_navss {
+   u-boot,dm-spl;
+};
+
+_mcu_wakeup {
+   u-boot,dm-spl;
+
+   timer1: timer@4040 {
+   compatible = "ti,omap5430-timer";
+   reg = <0x0 0x4040 0x0 0x80>;
+   ti,timer-alwon;
+   clock-frequency = <2500>;
+   u-boot,dm-spl;
+   };
+
+   chipid@4314 {
+   u-boot,dm-spl;
+   };
+};
+
+_navss {
+   u-boot,dm-spl;
+};
+
+_ringacc {
+   reg =   <0x0 0x2b80 0x0 0x40>,
+   <0x0 0x2b00 0x0 0x40>,
+   <0x0 0x2859 0x0 0x100>,
+   <0x0 0x2a50 0x0 0x4>,
+   <0x0 0x2844 0x0 0x4>;
+   reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
+   u-boot,dm-spl;
+};
+
+_udmap {
+   reg =   <0x0 0x285c 0x0 0x100>,
+   <0x0 0x284c 0x0 0x4000>,
+   <0x0 0x2a80 0x0 0x4>,
+   <0x0 0x284a 0x0 0x4000>,
+   <0x0 0x2aa0 0x0 0x4>,
+   <0x0 0x2840 0x0 0x2000>;
+   reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+   "tchanrt", "rflow";
+   u-boot,dm-spl;
+};
+
+_proxy_main {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   u-boot,dm-spl;
+   };
+};
+
+_pmx0 {
+   u-boot,dm-spl;
+};
+
+_uart8_pins_default {
+   

[PATCH v4 14/20] arm: dts: Add initial support for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
The J721S2 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration in automotive ADAS applications and
industrial applications requiring AI at the network edge. This SoC extends
the Jacinto 7 family of SoCs with focus on lowering system costs and power
while providing interfaces, memory architecture and compute performance for
single and multi-sensor applications.

Some highlights of this SoC are:

* Dual Cortex-A72s in a single cluster, three clusters of lockstep capable
dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x
floating point Vector DSP.
* 3D GPU: Automotive grade IMG BXS-4-64
* Vision Processing Accelerator (VPAC) with image signal processor and
Depth and Motion Processing Accelerator (DMPAC)
* Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface.
* Two Ethernet ports with RGMII support.
* Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems,
* Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller,
QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL
management.

See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021)
for further details: http://www.ti.com/lit/pdf/spruj28

Introduce basic support for the J721S2 SoC.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Nishanth Menon 
---
 arch/arm/dts/k3-j721s2-main.dtsi   | 937 +
 arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 302 
 arch/arm/dts/k3-j721s2.dtsi| 167 +
 3 files changed, 1406 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721s2-main.dtsi
 create mode 100644 arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi
 create mode 100644 arch/arm/dts/k3-j721s2.dtsi

diff --git a/arch/arm/dts/k3-j721s2-main.dtsi b/arch/arm/dts/k3-j721s2-main.dtsi
new file mode 100644
index ..976ba1e95aba
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-main.dtsi
@@ -0,0 +1,937 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for J721S2 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+_main {
+   msmc_ram: sram@7000 {
+   compatible = "mmio-sram";
+   reg = <0x0 0x7000 0x0 0x40>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x7000 0x40>;
+
+   atf-sram@0 {
+   reg = <0x0 0x2>;
+   };
+
+   tifs-sram@1f {
+   reg = <0x1f 0x1>;
+   };
+
+   l3cache-sram@20 {
+   reg = <0x20 0x20>;
+   };
+   };
+
+   gic500: interrupt-controller@180 {
+   compatible = "arm,gic-v3";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x00 0x0180 0x00 0x20>, /* GICD */
+ <0x00 0x0190 0x00 0x10>; /* GICR */
+
+   /* vcpumntirq: virtual CPU interface maintenance interrupt */
+   interrupts = ;
+
+   gic_its: msi-controller@182 {
+   compatible = "arm,gic-v3-its";
+   reg = <0x00 0x0182 0x00 0x1>;
+   socionext,synquacer-pre-its = <0x100 0x40>;
+   msi-controller;
+   #msi-cells = <1>;
+   };
+   };
+
+   main_gpio_intr: interrupt-controller@a0 {
+   compatible = "ti,sci-intr";
+   reg = <0x00 0x00a0 0x00 0x800>;
+   ti,intr-trigger-type = <1>;
+   interrupt-controller;
+   interrupt-parent = <>;
+   #interrupt-cells = <1>;
+   ti,sci = <>;
+   ti,sci-dev-id = <148>;
+   ti,interrupt-ranges = <8 360 56>;
+   };
+
+   main_pmx0: pinctrl@11c000 {
+   compatible = "pinctrl-single";
+   /* Proxy 0 addressing */
+   reg = <0x0 0x11c000 0x0 0x120>;
+   #pinctrl-cells = <1>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0x>;
+   };
+
+   main_uart0: serial@280 {
+   compatible = "ti,j721e-uart", "ti,am654-uart";
+   reg = <0x00 0x0280 0x00 0x200>;
+   interrupts = ;
+   current-speed = <115200>;
+   clocks = <_clks 146 3>;
+   clock-names = "fclk";
+   power-domains = <_pds 146 TI_SCI_PD_EXCLUSIVE>;
+   };
+
+   main_uart1: serial@281 {
+   compatible = "ti,j721e-uart", "ti,am654-uart";
+   reg = <0x00 0x0281 

[PATCH v4 15/20] arm: dts: Add initial support for J721S2 System on Module

2022-01-25 Thread Aswath Govindraju
A System on Module (SoM) contains the SoC, PMIC, DDR and basic high speed
components necessary for functionality. Therefore, add support for the
components present on the SoM.

Signed-off-by: Aswath Govindraju 
---
 arch/arm/dts/k3-j721s2-som-p0.dtsi | 173 +
 1 file changed, 173 insertions(+)
 create mode 100644 arch/arm/dts/k3-j721s2-som-p0.dtsi

diff --git a/arch/arm/dts/k3-j721s2-som-p0.dtsi 
b/arch/arm/dts/k3-j721s2-som-p0.dtsi
new file mode 100644
index ..c0687fece017
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-som-p0.dtsi
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-j721s2.dtsi"
+#include 
+
+/ {
+   memory@8000 {
+   device_type = "memory";
+   /* 16 GB RAM */
+   reg = <0x00 0x8000 0x00 0x8000>,
+ <0x08 0x8000 0x03 0x8000>;
+   };
+
+   reserved_memory: reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   secure_ddr: optee@9e80 {
+   reg = <0x00 0x9e80 0x00 0x0180>;
+   alignment = <0x1000>;
+   no-map;
+   };
+
+   };
+
+   transceiver0: can-phy0 {
+   /* standby pin has been grounded by default */
+   compatible = "ti,tcan1042";
+   #phy-cells = <0>;
+   max-bitrate = <500>;
+   };
+};
+
+_pmx0 {
+   main_i2c0_pins_default: main-i2c0-pins-default {
+   pinctrl-single,pins = <
+   J721S2_IOPAD(0x0e0, PIN_INPUT_PULLUP, 0) /* (AH25) 
I2C0_SCL */
+   J721S2_IOPAD(0x0e4, PIN_INPUT_PULLUP, 0) /* (AE24) 
I2C0_SDA */
+   >;
+   };
+
+   main_mcan16_pins_default: main-mcan16-pins-default {
+   pinctrl-single,pins = <
+   J721S2_IOPAD(0x028, PIN_INPUT, 0) /* (AB24) MCAN16_RX */
+   J721S2_IOPAD(0x024, PIN_OUTPUT, 0) /* (Y28) MCAN16_TX */
+   >;
+   };
+};
+
+_i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_pins_default>;
+   clock-frequency = <40>;
+
+   exp_som: gpio@21 {
+   compatible = "ti,tca6408";
+   reg = <0x21>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-line-names = "USB2.0_MUX_SEL", "CANUART_MUX1_SEL0",
+ "CANUART_MUX2_SEL0", "CANUART_MUX_SEL1",
+ "GPIO_RGMII1_RST", "GPIO_eDP_ENABLE",
+  "GPIO_LIN_EN", "CAN_STB";
+   };
+};
+
+_mcan16 {
+   pinctrl-0 = <_mcan16_pins_default>;
+   pinctrl-names = "default";
+   phys = <>;
+};
+
+_cluster0 {
+   status = "disabled";
+};
+
+_cluster1 {
+   status = "disabled";
+};
+
+_cluster2 {
+   status = "disabled";
+};
+
+_cluster3 {
+   status = "disabled";
+};
+
+_cluster4 {
+   status = "disabled";
+};
+
+_cluster5 {
+   status = "disabled";
+};
+
+_cluster6 {
+   status = "disabled";
+};
+
+_cluster7 {
+   status = "disabled";
+};
+
+_cluster8 {
+   status = "disabled";
+};
+
+_cluster9 {
+   status = "disabled";
+};
+
+_cluster10 {
+   status = "disabled";
+};
+
+_cluster11 {
+   status = "disabled";
+};
+
+_cluster0 {
+   status = "disabled";
+};
+
+_cluster1 {
+   status = "disabled";
+};
+
+_cluster2 {
+   status = "disabled";
+};
+
+_cluster3 {
+   status = "disabled";
+};
+
+_cluster4 {
+   status = "disabled";
+};
+
+_cluster5 {
+   status = "disabled";
+};
+
+_cluster6 {
+   status = "disabled";
+};
+
+_cluster7 {
+   status = "disabled";
+};
+
+_cluster8 {
+   status = "disabled";
+};
+
+_cluster9 {
+   status = "disabled";
+};
+
+_cluster10 {
+   status = "disabled";
+};
+
+_cluster11 {
+   status = "disabled";
+};
-- 
2.17.1



[PATCH v4 13/20] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2

2022-01-25 Thread Aswath Govindraju
Add pinctrl macros for J721S2 SoC. These macro definitions are
similar to that of J721E, but adding new definitions to avoid
any naming confusions in the soc dts files.

checkpatch insists the following error exists:
ERROR: Macros with complex values should be enclosed in parentheses

However, we do not need parentheses enclosing the values for this
macro as we do intend it to generate two separate values as has been
done for other similar platforms.

Signed-off-by: Aswath Govindraju 
---
 include/dt-bindings/pinctrl/k3.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
index e085f102b283..63e038e36ca3 100644
--- a/include/dt-bindings/pinctrl/k3.h
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -38,4 +38,7 @@
 #define AM64X_IOPAD(pa, val, muxmode)  (((pa) & 0x1fff)) ((val) | 
(muxmode))
 #define AM64X_MCU_IOPAD(pa, val, muxmode)  (((pa) & 0x1fff)) ((val) | 
(muxmode))
 
+#define J721S2_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | 
(muxmode))
+#define J721S2_WKUP_IOPAD(pa, val, muxmode)(((pa) & 0x1fff)) ((val) | 
(muxmode))
+
 #endif
-- 
2.17.1



[PATCH v4 12/20] dt-bindings: ti-serdes-mux: Add defines for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
There are 4 lanes in the single instance of J721S2 SERDES. Each SERDES
lane mux can select upto 4 different IPs. Define all the possible
functions.

Signed-off-by: Aswath Govindraju 
---
 include/dt-bindings/mux/ti-serdes.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/dt-bindings/mux/ti-serdes.h 
b/include/dt-bindings/mux/ti-serdes.h
index d417b9268b16..d3116c52ab72 100644
--- a/include/dt-bindings/mux/ti-serdes.h
+++ b/include/dt-bindings/mux/ti-serdes.h
@@ -95,4 +95,26 @@
 #define AM64_SERDES0_LANE0_PCIE0   0x0
 #define AM64_SERDES0_LANE0_USB 0x1
 
+/* J721S2 */
+
+#define J721S2_SERDES0_LANE0_EDP_LANE0 0x0
+#define J721S2_SERDES0_LANE0_PCIE1_LANE0   0x1
+#define J721S2_SERDES0_LANE0_IP3_UNUSED0x2
+#define J721S2_SERDES0_LANE0_IP4_UNUSED0x3
+
+#define J721S2_SERDES0_LANE1_EDP_LANE1 0x0
+#define J721S2_SERDES0_LANE1_PCIE1_LANE1   0x1
+#define J721S2_SERDES0_LANE1_USB   0x2
+#define J721S2_SERDES0_LANE1_IP4_UNUSED0x3
+
+#define J721S2_SERDES0_LANE2_EDP_LANE2 0x0
+#define J721S2_SERDES0_LANE2_PCIE1_LANE2   0x1
+#define J721S2_SERDES0_LANE2_IP3_UNUSED0x2
+#define J721S2_SERDES0_LANE2_IP4_UNUSED0x3
+
+#define J721S2_SERDES0_LANE3_EDP_LANE3 0x0
+#define J721S2_SERDES0_LANE3_PCIE1_LANE3   0x1
+#define J721S2_SERDES0_LANE3_USB   0x2
+#define J721S2_SERDES0_LANE3_IP4_UNUSED0x3
+
 #endif /* _DT_BINDINGS_MUX_TI_SERDES */
-- 
2.17.1



[PATCH v4 11/20] board: ti: j721s2: Add board support for J721S2

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add board support for J721S2 SoC.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 board/ti/j721s2/Kconfig |  63 +
 board/ti/j721s2/MAINTAINERS |  16 
 board/ti/j721s2/Makefile|   8 ++
 board/ti/j721s2/evm.c   | 180 
 4 files changed, 267 insertions(+)
 create mode 100644 board/ti/j721s2/Kconfig
 create mode 100644 board/ti/j721s2/MAINTAINERS
 create mode 100644 board/ti/j721s2/Makefile
 create mode 100644 board/ti/j721s2/evm.c

diff --git a/board/ti/j721s2/Kconfig b/board/ti/j721s2/Kconfig
new file mode 100644
index ..2e115f14171d
--- /dev/null
+++ b/board/ti/j721s2/Kconfig
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+#  David Huang 
+
+choice
+   prompt "K3 J721S2 board"
+   optional
+
+config TARGET_J721S2_A72_EVM
+   bool "TI K3 based J721S2 EVM running on A72"
+   select ARM64
+   select SOC_K3_J721S2
+   select BOARD_LATE_INIT
+   imply TI_I2C_BOARD_DETECT
+   select SYS_DISABLE_DCACHE_OPS
+
+config TARGET_J721S2_R5_EVM
+   bool "TI K3 based J721S2 EVM running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select SOC_K3_J721S2
+   select K3_LOAD_SYSFW
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
+   imply SYS_K3_SPL_ATF
+   imply TI_I2C_BOARD_DETECT
+
+endchoice
+
+if TARGET_J721S2_A72_EVM
+
+config SYS_BOARD
+   default "j721s2"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "j721s2_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_J721S2_R5_EVM
+
+config SYS_BOARD
+   default "j721s2"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "j721s2_evm"
+
+config SPL_LDSCRIPT
+   default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+source "board/ti/common/Kconfig"
+
+endif
diff --git a/board/ti/j721s2/MAINTAINERS b/board/ti/j721s2/MAINTAINERS
new file mode 100644
index ..323bd2353a7e
--- /dev/null
+++ b/board/ti/j721s2/MAINTAINERS
@@ -0,0 +1,16 @@
+J721S2 BOARD
+M: Aswath Govindraju 
+S: Maintained
+F: board/ti/j721s2
+F: include/configs/j721s2_evm.h
+F: configs/j721s2_evm_r5_defconfig
+F: configs/j721s2_evm_a72_defconfig
+F: arch/arm/dts/k3-j721s2.dtsi
+F: arch/arm/dts/k3-j721s2-main.dtsi
+F: arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi
+F: arch/arm/dts/k3-j721s2-som-p0.dtsi
+F: arch/arm/dts/k3-j721s2-common-proc-board.dts
+F: arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
+F: arch/arm/dts//k3-j721s2-r5-common-proc-board.dts
+F: arch/arm/dts/k3-j721s2-ddr.dtsi
+F: arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi
diff --git a/board/ti/j721s2/Makefile b/board/ti/j721s2/Makefile
new file mode 100644
index ..9dced1269942
--- /dev/null
+++ b/board/ti/j721s2/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+#  David Huang 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += evm.o
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
new file mode 100644
index ..3c75ecfc0fe4
--- /dev/null
+++ b/board/ti/j721s2/evm.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for J721S2 EVM
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
+ * David Huang 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../common/board_detect.h"
+
+#define board_is_j721s2_som()  board_ti_k3_is("J721S2X-PM1-SOM")
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+#ifdef CONFIG_PHYS_64BIT
+   gd->ram_size = 0x1;
+#else
+   gd->ram_size = 0x8000;
+#endif
+
+   return 0;
+}
+
+ulong board_get_usable_ram_top(ulong total_size)
+{
+#ifdef CONFIG_PHYS_64BIT
+   /* Limit RAM used by U-Boot to the DDR low region */
+   if (gd->ram_top > 0x1)
+   return 0x1;
+#endif
+
+   return gd->ram_top;
+}
+
+int dram_init_banksize(void)
+{
+   /* Bank 0 declares the memory available in the DDR low region */
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].size = 0x7fff;
+   gd->ram_size = 0x8000;
+
+#ifdef CONFIG_PHYS_64BIT
+   /* Bank 1 declares the memory available in the DDR high region */
+   gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE1;
+   gd->bd->bi_dram[1].size = 0x37fff;
+   gd->ram_size = 0x4;
+#endif
+
+   return 0;
+}
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   if (!strcmp(name, "k3-j721s2-common-proc-board"))
+   return 

[PATCH v4 10/20] soc: ti: k3-socinfo: Add entry for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add support for J721S2 SoC identification.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 drivers/soc/soc_ti_k3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 9abed7d490a2..c8f7a5768775 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -14,6 +14,7 @@
 #define J721E  0xbb64
 #define J7200  0xbb6d
 #define AM64X  0xbb38
+#define J721S2 0xbb75
 
 #define REV_SR1_0  0
 #define REV_SR2_0  1
@@ -48,6 +49,9 @@ static const char *get_family_string(u32 idreg)
case AM64X:
family = "AM64X";
break;
+   case J721S2:
+   family = "J721S2";
+   break;
default:
family = "Unknown Silicon";
};
-- 
2.17.1



[PATCH v4 09/20] ram: k3-ddrss: Add support for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add support for DDR subsystem in J721S2 SoC.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 drivers/ram/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index a79594d35198..709c916a2a11 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -62,7 +62,7 @@ choice
depends on K3_DDRSS
prompt "K3 DDRSS Arch Support"
 
-   default K3_J721E_DDRSS if SOC_K3_J721E
+   default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2
default K3_AM64_DDRSS if SOC_K3_AM642
 
 config K3_J721E_DDRSS
-- 
2.17.1



[PATCH v4 08/20] power: domain: ti: Add support for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add support for J721S2 SoC.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 drivers/power/domain/ti-power-domain.c | 5 +
 include/k3-dev.h   | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/power/domain/ti-power-domain.c 
b/drivers/power/domain/ti-power-domain.c
index 4fe31686bd35..6af5dbb24191 100644
--- a/drivers/power/domain/ti-power-domain.c
+++ b/drivers/power/domain/ti-power-domain.c
@@ -81,6 +81,11 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
.family = "J7200",
.data = _pd_platdata,
},
+#elif CONFIG_SOC_K3_J721S2
+   {
+   .family = "J721S2",
+   .data = _pd_platdata,
+   },
 #endif
{ /* sentinel */ }
 };
diff --git a/include/k3-dev.h b/include/k3-dev.h
index 55c5057db35a..b46b8c3aabc7 100644
--- a/include/k3-dev.h
+++ b/include/k3-dev.h
@@ -77,6 +77,7 @@ struct ti_k3_pd_platdata {
 
 extern const struct ti_k3_pd_platdata j721e_pd_platdata;
 extern const struct ti_k3_pd_platdata j7200_pd_platdata;
+extern const struct ti_k3_pd_platdata j721s2_pd_platdata;
 
 u8 ti_pd_state(struct ti_pd *pd);
 u8 lpsc_get_state(struct ti_lpsc *lpsc);
-- 
2.17.1



[PATCH v4 07/20] clk: clk-k3: Add support for J721S2 SoC

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add support for J721S2 SoC.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 drivers/clk/ti/clk-k3.c | 5 +
 include/k3-clk.h| 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c
index e04c57eff252..74beb4d8ebda 100644
--- a/drivers/clk/ti/clk-k3.c
+++ b/drivers/clk/ti/clk-k3.c
@@ -68,6 +68,11 @@ static const struct soc_attr ti_k3_soc_clk_data[] = {
.family = "J7200",
.data = _clk_platdata,
},
+#elif CONFIG_SOC_K3_J721S2
+   {
+   .family = "J721S2",
+   .data = _clk_platdata,
+   },
 #endif
{ /* sentinel */ }
 };
diff --git a/include/k3-clk.h b/include/k3-clk.h
index 59c76db86ead..31292b59f20c 100644
--- a/include/k3-clk.h
+++ b/include/k3-clk.h
@@ -173,6 +173,7 @@ struct ti_k3_clk_platdata {
 
 extern const struct ti_k3_clk_platdata j721e_clk_platdata;
 extern const struct ti_k3_clk_platdata j7200_clk_platdata;
+extern const struct ti_k3_clk_platdata j721s2_clk_platdata;
 
 struct clk *clk_register_ti_pll(const char *name, const char *parent_name,
void __iomem *reg);
-- 
2.17.1



[PATCH v4 06/20] drivers: dma: Add support for J721S2

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add support for DMA in J721S2 SoC.

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
---
 drivers/dma/ti/Makefile   |   1 +
 drivers/dma/ti/k3-psil-j721s2.c   | 167 ++
 drivers/dma/ti/k3-psil-priv.h |   1 +
 drivers/dma/ti/k3-psil.c  |   2 +
 drivers/firmware/ti_sci_static_data.h |  40 +-
 5 files changed, 208 insertions(+), 3 deletions(-)
 create mode 100644 drivers/dma/ti/k3-psil-j721s2.c

diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 0391cd3d80c9..6a4f4f1365bd 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_TI_K3_PSIL) += k3-psil-data.o
 k3-psil-data-y += k3-psil.o
 k3-psil-data-$(CONFIG_SOC_K3_AM6) += k3-psil-am654.o
 k3-psil-data-$(CONFIG_SOC_K3_J721E) += k3-psil-j721e.o
+k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
 k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
diff --git a/drivers/dma/ti/k3-psil-j721s2.c b/drivers/dma/ti/k3-psil-j721s2.c
new file mode 100644
index ..4c4172a4d271
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-j721s2.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#include 
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   },  \
+   }
+
+#define PSIL_PDMA_XY_PKT(x)\
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   .pkt_mode = 1,  \
+   },  \
+   }
+
+#define PSIL_PDMA_MCASP(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   .pdma_acc32 = 1,\
+   .pdma_burst = 1,\
+   },  \
+   }
+
+#define PSIL_ETHERNET(x)   \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 16, \
+   },  \
+   }
+
+#define PSIL_SA2UL(x, tx)  \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 64, \
+   .notdpkt = tx,  \
+   },  \
+   }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep j721s2_src_ep_map[] = {
+   /* PDMA_MCASP - McASP0-4 */
+   PSIL_PDMA_MCASP(0x4400),
+   PSIL_PDMA_MCASP(0x4401),
+   PSIL_PDMA_MCASP(0x4402),
+   PSIL_PDMA_MCASP(0x4403),
+   PSIL_PDMA_MCASP(0x4404),
+   /* PDMA_SPI_G0 - SPI0-3 */
+   PSIL_PDMA_XY_PKT(0x4600),
+   PSIL_PDMA_XY_PKT(0x4601),
+   PSIL_PDMA_XY_PKT(0x4602),
+   PSIL_PDMA_XY_PKT(0x4603),
+   PSIL_PDMA_XY_PKT(0x4604),
+   PSIL_PDMA_XY_PKT(0x4605),
+   PSIL_PDMA_XY_PKT(0x4606),
+   PSIL_PDMA_XY_PKT(0x4607),
+   PSIL_PDMA_XY_PKT(0x4608),
+   PSIL_PDMA_XY_PKT(0x4609),
+   PSIL_PDMA_XY_PKT(0x460a),
+   PSIL_PDMA_XY_PKT(0x460b),
+   PSIL_PDMA_XY_PKT(0x460c),
+   PSIL_PDMA_XY_PKT(0x460d),
+   PSIL_PDMA_XY_PKT(0x460e),
+   PSIL_PDMA_XY_PKT(0x460f),
+   /* PDMA_SPI_G1 - SPI4-7 */
+   PSIL_PDMA_XY_PKT(0x4610),
+   PSIL_PDMA_XY_PKT(0x4611),
+   PSIL_PDMA_XY_PKT(0x4612),
+   PSIL_PDMA_XY_PKT(0x4613),
+   PSIL_PDMA_XY_PKT(0x4614),
+   PSIL_PDMA_XY_PKT(0x4615),
+   PSIL_PDMA_XY_PKT(0x4616),
+   PSIL_PDMA_XY_PKT(0x4617),
+   PSIL_PDMA_XY_PKT(0x4618),
+   PSIL_PDMA_XY_PKT(0x4619),
+   

[PATCH v4 05/20] arm: K3: Add basic support for J721S2 SoC definition

2022-01-25 Thread Aswath Govindraju
From: David Huang 

Add basic support for J721S2 SoC definition

Signed-off-by: David Huang 
Signed-off-by: Aswath Govindraju 
Signed-off-by: Dave Gerlach 
Signed-off-by: Nishanth Menon 
Signed-off-by: Hari Nagalla 
---
 arch/arm/mach-k3/Kconfig  |  15 +-
 arch/arm/mach-k3/Makefile |   1 +
 arch/arm/mach-k3/arm64-mmu.c  |  41 ++
 arch/arm/mach-k3/include/mach/hardware.h  |   4 +
 .../mach-k3/include/mach/j721s2_hardware.h|  60 +++
 arch/arm/mach-k3/include/mach/j721s2_spl.h|  46 ++
 arch/arm/mach-k3/include/mach/spl.h   |   4 +
 arch/arm/mach-k3/j721s2/Makefile  |   5 +
 arch/arm/mach-k3/j721s2/clk-data.c| 403 ++
 arch/arm/mach-k3/j721s2/dev-data.c|  85 
 arch/arm/mach-k3/j721s2_init.c| 312 ++
 include/configs/j721s2_evm.h  | 191 +
 12 files changed, 1162 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-k3/include/mach/j721s2_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/j721s2_spl.h
 create mode 100644 arch/arm/mach-k3/j721s2/Makefile
 create mode 100644 arch/arm/mach-k3/j721s2/clk-data.c
 create mode 100644 arch/arm/mach-k3/j721s2/dev-data.c
 create mode 100644 arch/arm/mach-k3/j721s2_init.c
 create mode 100644 include/configs/j721s2_evm.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 526f5f8b76c2..a01bf2351499 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -10,6 +10,9 @@ config SOC_K3_AM6
 config SOC_K3_J721E
bool "TI's K3 based J721E SoC Family Support"
 
+config SOC_K3_J721S2
+   bool "TI's K3 based J721S2 SoC Family Support"
+
 config SOC_K3_AM642
bool "TI's K3 based AM642 SoC Family Support"
 
@@ -21,7 +24,7 @@ config SYS_SOC
 config SYS_K3_NON_SECURE_MSRAM_SIZE
hex
default 0x8 if SOC_K3_AM6
-   default 0x10 if SOC_K3_J721E
+   default 0x10 if SOC_K3_J721E || SOC_K3_J721S2
default 0x1c if SOC_K3_AM642
help
  Describes the total size of the MCU or OCMC MSRAM present on
@@ -32,7 +35,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE
 config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
hex
default 0x58000 if SOC_K3_AM6
-   default 0xc if SOC_K3_J721E
+   default 0xc if SOC_K3_J721E || SOC_K3_J721S2
default 0x18 if SOC_K3_AM642
help
  Describes the maximum size of the image that ROM can download
@@ -41,14 +44,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
 config SYS_K3_MCU_SCRATCHPAD_BASE
hex
default 0x4028 if SOC_K3_AM6
-   default 0x4028 if SOC_K3_J721E
+   default 0x4028 if SOC_K3_J721E || SOC_K3_J721S2
help
  Describes the base address of MCU Scratchpad RAM.
 
 config SYS_K3_MCU_SCRATCHPAD_SIZE
hex
default 0x200 if SOC_K3_AM6
-   default 0x200 if SOC_K3_J721E
+   default 0x200 if SOC_K3_J721E || SOC_K3_J721S2
help
  Describes the size of MCU Scratchpad RAM.
 
@@ -56,6 +59,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
hex
default 0x41c7fbfc if SOC_K3_AM6
default 0x41cffbfc if SOC_K3_J721E
+   default 0x41cfdbfc if SOC_K3_J721S2
default 0x701bebfc if SOC_K3_AM642
help
  Address at which ROM stores the value which determines if SPL
@@ -156,7 +160,7 @@ config K3_ATF_LOAD_ADDR
 
 config K3_DM_FW
bool "Separate DM firmware image"
-   depends on SPL && CPU_V7R && SOC_K3_J721E && !CLK_TI_SCI && 
!TI_SCI_POWER_DOMAIN
+   depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2) && 
!CLK_TI_SCI && !TI_SCI_POWER_DOMAIN
default y
help
  Enabling this will indicate that the system has separate DM
@@ -169,4 +173,5 @@ source "board/ti/am65x/Kconfig"
 source "board/ti/am64x/Kconfig"
 source "board/ti/j721e/Kconfig"
 source "board/siemens/iot2050/Kconfig"
+source "board/ti/j721s2/Kconfig"
 endif
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 47cf7b6d17a8..c0a6a9c87d8f 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -5,6 +5,7 @@
 
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
 obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o j721e/ j7200/
+obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o j721s2/
 obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 94242e1e5cc3..527e66431888 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -181,6 +181,47 @@ struct mm_region *mem_map = j7200_mem_map;
 
 #endif /* CONFIG_SOC_K3_J721E */
 
+#ifdef CONFIG_SOC_K3_J721S2
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
+
+/* ToDo: Add 64bit IO */
+struct mm_region j721s2_mem_map[NR_MMU_REGIONS] = {
+   {
+   .virt = 0x0UL,
+   

[PATCH v4 04/20] ram: k3-ddrss: Add support for configuring MSMC subsystem in case of Multiple DDR subsystems

2022-01-25 Thread Aswath Govindraju
In Multi DDR subystems with interleaving support, the following needs to
configured,

- interleaving granular size and region
- EMIFs to be enabled
- EMIFs with ecc to be enabled
- EMIF separated or interleaved
- number of cycles of unsuccessful EMIF arbitration to wait before
  arbitrating for a different EMIF port, by default set to 3

Add support for configuring all the above by using a MSMC device

Signed-off-by: Aswath Govindraju 
---
 drivers/ram/k3-ddrss/k3-ddrss.c | 158 
 1 file changed, 158 insertions(+)

diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index 96084d0b83d9..25e3976e6569 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -33,6 +33,75 @@
 #define SINGLE_DDR_SUBSYSTEM   0x1
 #define MULTI_DDR_SUBSYSTEM0x2
 
+#define MULTI_DDR_CFG0  0x00114100
+#define MULTI_DDR_CFG1  0x00114104
+#define DDR_CFG_LOAD0x00114110
+
+enum intrlv_gran {
+   GRAN_128B,
+   GRAN_512B,
+   GRAN_2KB,
+   GRAN_4KB,
+   GRAN_16KB,
+   GRAN_32KB,
+   GRAN_512KB,
+   GRAN_1GB,
+   GRAN_1_5GB,
+   GRAN_2GB,
+   GRAN_3GB,
+   GRAN_4GB,
+   GRAN_6GB,
+   GRAN_8GB,
+   GRAN_16GB
+};
+
+enum intrlv_size {
+   SIZE_0,
+   SIZE_128MB,
+   SIZE_256MB,
+   SIZE_512MB,
+   SIZE_1GB,
+   SIZE_2GB,
+   SIZE_3GB,
+   SIZE_4GB,
+   SIZE_6GB,
+   SIZE_8GB,
+   SIZE_12GB,
+   SIZE_16GB,
+   SIZE_32GB
+};
+
+struct k3_ddrss_data {
+   u32 flags;
+};
+
+enum ecc_enable {
+   DISABLE_ALL = 0,
+   ENABLE_0,
+   ENABLE_1,
+   ENABLE_ALL
+};
+
+enum emif_config {
+   INTERLEAVE_ALL = 0,
+   SEPR0,
+   SEPR1
+};
+
+enum emif_active {
+   EMIF_0 = 1,
+   EMIF_1,
+   EMIF_ALL
+};
+
+struct k3_msmc {
+   enum intrlv_gran gran;
+   enum intrlv_size size;
+   enum ecc_enable enable;
+   enum emif_config config;
+   enum emif_active active;
+};
+
 struct k3_ddrss_desc {
struct udevice *dev;
void __iomem *ddrss_ss_cfg;
@@ -512,3 +581,92 @@ U_BOOT_DRIVER(k3_ddrss) = {
.probe  = k3_ddrss_probe,
.priv_auto  = sizeof(struct k3_ddrss_desc),
 };
+
+static int k3_msmc_set_config(struct k3_msmc *msmc)
+{
+   u32 ddr_cfg0 = 0;
+   u32 ddr_cfg1 = 0;
+
+   ddr_cfg0 |= msmc->gran << 24;
+   ddr_cfg0 |= msmc->size << 16;
+   /* heartbeat_per, bit[4:0] setting to 3 is advisable */
+   ddr_cfg0 |= 3;
+
+   /* Program MULTI_DDR_CFG0 */
+   writel(ddr_cfg0, MULTI_DDR_CFG0);
+
+   ddr_cfg1 |= msmc->enable << 16;
+   ddr_cfg1 |= msmc->config << 8;
+   ddr_cfg1 |= msmc->active;
+
+   /* Program MULTI_DDR_CFG1 */
+   writel(ddr_cfg1, MULTI_DDR_CFG1);
+
+   /* Program DDR_CFG_LOAD */
+   writel(0x6000, DDR_CFG_LOAD);
+
+   return 0;
+}
+
+static int k3_msmc_probe(struct udevice *dev)
+{
+   struct k3_msmc *msmc = dev_get_priv(dev);
+   int ret = 0;
+
+   /* Read the granular size from DT */
+   ret = dev_read_u32(dev, "intrlv-gran", >gran);
+   if (ret) {
+   dev_err(dev, "missing intrlv-gran property");
+   return -EINVAL;
+   }
+
+   /* Read the interleave region from DT */
+   ret = dev_read_u32(dev, "intrlv-size", >size);
+   if (ret) {
+   dev_err(dev, "missing intrlv-size property");
+   return -EINVAL;
+   }
+
+   /* Read ECC enable config */
+   ret = dev_read_u32(dev, "ecc-enable", >enable);
+   if (ret) {
+   dev_err(dev, "missing ecc-enable property");
+   return -EINVAL;
+   }
+
+   /* Read EMIF configuration */
+   ret = dev_read_u32(dev, "emif-config", >config);
+   if (ret) {
+   dev_err(dev, "missing emif-config property");
+   return -EINVAL;
+   }
+
+   /* Read EMIF active */
+   ret = dev_read_u32(dev, "emif-active", >active);
+   if (ret) {
+   dev_err(dev, "missing emif-active property");
+   return -EINVAL;
+   }
+
+   ret = k3_msmc_set_config(msmc);
+   if (ret) {
+   dev_err(dev, "error setting msmc config");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static const struct udevice_id k3_msmc_ids[] = {
+   { .compatible = "ti,j721s2-msmc"},
+   {}
+};
+
+U_BOOT_DRIVER(k3_msmc) = {
+   .name = "k3_msmc",
+   .of_match = k3_msmc_ids,
+   .id = UCLASS_MISC,
+   .probe = k3_msmc_probe,
+   .priv_auto = sizeof(struct k3_msmc),
+   .flags = DM_FLAG_DEFAULT_PD_CTRL_OFF,
+};
-- 
2.17.1



[PATCH v4 03/20] ram: k3-ddrss: Add support for multiple instances of DDR subsystems

2022-01-25 Thread Aswath Govindraju
The current driver only supports single instance of DRR subsystem. Add
support for probing multiple instances of DDR subsystem.

Signed-off-by: Aswath Govindraju 
---
 drivers/ram/k3-ddrss/k3-ddrss.c | 138 
 1 file changed, 87 insertions(+), 51 deletions(-)

diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index 95b5cf9128b0..96084d0b83d9 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -30,6 +30,9 @@
 #define DDRSS_V2A_R1_MAT_REG   0x0020
 #define DDRSS_ECC_CTRL_REG 0x0120
 
+#define SINGLE_DDR_SUBSYSTEM   0x1
+#define MULTI_DDR_SUBSYSTEM0x2
+
 struct k3_ddrss_desc {
struct udevice *dev;
void __iomem *ddrss_ss_cfg;
@@ -42,14 +45,12 @@ struct k3_ddrss_desc {
u32 ddr_freq2;
u32 ddr_fhs_cnt;
struct udevice *vtt_supply;
+   u32 instance;
+   lpddr4_obj *driverdt;
+   lpddr4_config config;
+   lpddr4_privatedata pd;
 };
 
-static lpddr4_obj *driverdt;
-static lpddr4_config config;
-static lpddr4_privatedata pd;
-
-static struct k3_ddrss_desc *ddrss;
-
 struct reginitdata {
u32 ctl_regs[LPDDR4_INTR_CTL_REG_COUNT];
u16 ctl_regs_offs[LPDDR4_INTR_CTL_REG_COUNT];
@@ -83,15 +84,16 @@ struct reginitdata {
offset = offset * 10 + (*i - '0'); } \
} while (0)
 
-static u32 k3_lpddr4_read_ddr_type(void)
+static u32 k3_lpddr4_read_ddr_type(const lpddr4_privatedata *pd)
 {
u32 status = 0U;
u32 offset = 0U;
u32 regval = 0U;
u32 dram_class = 0U;
+   struct k3_ddrss_desc *ddrss = (struct k3_ddrss_desc *)pd->ddr_instance;
 
TH_OFFSET_FROM_REG(LPDDR4__DRAM_CLASS__REG, CTL_SHIFT, offset);
-   status = driverdt->readreg(, LPDDR4_CTL_REGS, offset, );
+   status = ddrss->driverdt->readreg(pd, LPDDR4_CTL_REGS, offset, );
if (status > 0U) {
printf("%s: Failed to read DRAM_CLASS\n", __func__);
hang();
@@ -102,23 +104,23 @@ static u32 k3_lpddr4_read_ddr_type(void)
return dram_class;
 }
 
-static void k3_lpddr4_freq_update(void)
+static void k3_lpddr4_freq_update(struct k3_ddrss_desc *ddrss)
 {
unsigned int req_type, counter;
 
for (counter = 0; counter < ddrss->ddr_fhs_cnt; counter++) {
if (wait_for_bit_le32(ddrss->ddrss_ctrl_mmr +
- CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS, 0x80,
+ CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS + 
ddrss->instance * 0x10, 0x80,
  true, 1, false)) {
printf("Timeout during frequency handshake\n");
hang();
}
 
req_type = readl(ddrss->ddrss_ctrl_mmr +
-CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS) & 0x03;
+CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS + 
ddrss->instance * 0x10) & 0x03;
 
-   debug("%s: received freq change req: req type = %d, req no. = 
%d\n",
- __func__, req_type, counter);
+   debug("%s: received freq change req: req type = %d, req no. = 
%d, instance = %d\n",
+ __func__, req_type, counter, ddrss->instance);
 
if (req_type == 1)
clk_set_rate(>ddr_clk, ddrss->ddr_freq1);
@@ -132,31 +134,32 @@ static void k3_lpddr4_freq_update(void)
printf("%s: Invalid freq request type\n", __func__);
 
writel(0x1, ddrss->ddrss_ctrl_mmr +
-  CTRLMMR_DDR4_FSP_CLKCHNG_ACK_OFFS);
+  CTRLMMR_DDR4_FSP_CLKCHNG_ACK_OFFS + ddrss->instance * 
0x10);
if (wait_for_bit_le32(ddrss->ddrss_ctrl_mmr +
- CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS, 0x80,
+ CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS + 
ddrss->instance * 0x10, 0x80,
  false, 10, false)) {
printf("Timeout during frequency handshake\n");
hang();
}
writel(0x0, ddrss->ddrss_ctrl_mmr +
-  CTRLMMR_DDR4_FSP_CLKCHNG_ACK_OFFS);
+  CTRLMMR_DDR4_FSP_CLKCHNG_ACK_OFFS + ddrss->instance * 
0x10);
}
 }
 
-static void k3_lpddr4_ack_freq_upd_req(void)
+static void k3_lpddr4_ack_freq_upd_req(const lpddr4_privatedata *pd)
 {
u32 dram_class;
+   struct k3_ddrss_desc *ddrss = (struct k3_ddrss_desc *)pd->ddr_instance;
 
debug("--->>> LPDDR4 Initialization is in progress ... <<<---\n");
 
-   dram_class = k3_lpddr4_read_ddr_type();
+   dram_class = k3_lpddr4_read_ddr_type(pd);
 
switch (dram_class) {
case DENALI_CTL_0_DRAM_CLASS_DDR4:
break;
case DENALI_CTL_0_DRAM_CLASS_LPDDR4:
-   k3_lpddr4_freq_update();
+   

[PATCH v4 00/20] J721S2: Add initial support

2022-01-25 Thread Aswath Govindraju
The J721S2 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration in automotive ADAS applications and
industrial applications requiring AI at the network edge. This SoC extends
the Jacinto 7 family of SoCs with focus on lowering system costs and power
while providing interfaces, memory architecture and compute performance for
single and multi-sensor applications.

Some highlights of this SoC are:

* Dual Cortex-A72s in a single cluster, three clusters of lockstep capable
dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x
floating point Vector DSP.
* 3D GPU: Automotive grade IMG BXS-4-64
* Vision Processing Accelerator (VPAC) with image signal processor and
Depth and Motion Processing Accelerator (DMPAC)
* Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface.
* Two Ethernet ports with RGMII support.
* Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems,
* Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller,
QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL
management.
* Chips and Media Wave521CL H.264/H.265 encode/decode engine

See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021)
for further details: http://www.ti.com/lit/pdf/spruj28

bootlog:
 - https://pastebin.ubuntu.com/p/NkwRvJH5Gg/

Notes:
- Patches 12, 13, 14, 15 and 16 are synced from upstream kernel v5.17-rc1
  tag

Changes since v3:
- Fixed the MMU mapping to standard in patch 5 based on the comments
  received from Suman.

Changes since v2:
- Removed the redundant config K3_J721S2_DDRSS and instead used
  K3_J721E_DDRSS
- Formatted the Kconfig files to remove extra lines
- Added dts files in the MAINTAINERS baord folder

Changes since v1:
- Removed unused serial aliases
- Assigned serial2 alias for main uart8 instance
- Moved aliases to respective board files

Aswath Govindraju (10):
  ram: k3-ddrss: lpddr4_structs_if.h: Add a pointer to ddr instance
  ram: k3-ddrss: Add support for multiple instances of DDR subsystems
  ram: k3-ddrss: Add support for configuring MSMC subsystem in case of
Multiple DDR subsystems
  dt-bindings: ti-serdes-mux: Add defines for J721S2 SoC
  dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2
  arm: dts: Add initial support for J721S2 SoC
  arm: dts: Add initial support for J721S2 System on Module
  arm: dts: Add support for A72 specific J721S2 Common Processor Board
  arm: dts: k3-j721s2: Add r5 specific dt support
  arm: dts: k3-j721s2-ddr: Add DDR support

David Huang (9):
  arm: K3: Add basic support for J721S2 SoC definition
  drivers: dma: Add support for J721S2
  clk: clk-k3: Add support for J721S2 SoC
  power: domain: ti: Add support for J721S2 SoC
  ram: k3-ddrss: Add support for J721S2 SoC
  soc: ti: k3-socinfo: Add entry for J721S2 SoC
  board: ti: j721s2: Add board support for J721S2
  configs: j721s2_evm_r5_defconfig: Add R5 SPL specific defconfig
  configs: j721s2_evm_a72_defconfig: Add A72 specific defconfig

Nishanth Menon (1):
  remoteproc: k3_system_controller: Support optional boot_notification
channel

 arch/arm/dts/Makefile |2 +
 .../k3-j721s2-common-proc-board-u-boot.dtsi   |  149 +
 arch/arm/dts/k3-j721s2-common-proc-board.dts  |  430 ++
 arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi  | 4387 
 arch/arm/dts/k3-j721s2-ddr.dtsi   | 4440 +
 arch/arm/dts/k3-j721s2-main.dtsi  |  937 
 arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi|  302 ++
 .../dts/k3-j721s2-r5-common-proc-board.dts|  198 +
 arch/arm/dts/k3-j721s2-som-p0.dtsi|  173 +
 arch/arm/dts/k3-j721s2.dtsi   |  167 +
 arch/arm/mach-k3/Kconfig  |   15 +-
 arch/arm/mach-k3/Makefile |1 +
 arch/arm/mach-k3/arm64-mmu.c  |   41 +
 arch/arm/mach-k3/include/mach/hardware.h  |4 +
 .../mach-k3/include/mach/j721s2_hardware.h|   60 +
 arch/arm/mach-k3/include/mach/j721s2_spl.h|   46 +
 arch/arm/mach-k3/include/mach/spl.h   |4 +
 arch/arm/mach-k3/j721s2/Makefile  |5 +
 arch/arm/mach-k3/j721s2/clk-data.c|  403 ++
 arch/arm/mach-k3/j721s2/dev-data.c|   85 +
 arch/arm/mach-k3/j721s2_init.c|  312 ++
 board/ti/j721s2/Kconfig   |   63 +
 board/ti/j721s2/MAINTAINERS   |   16 +
 board/ti/j721s2/Makefile  |8 +
 board/ti/j721s2/evm.c |  180 +
 configs/j721s2_evm_a72_defconfig  |  207 +
 configs/j721s2_evm_r5_defconfig   |  171 +
 .../remoteproc/k3-system-controller.txt   |3 +
 drivers/clk/ti/clk-k3.c   |5 +
 drivers/dma/ti/Makefile   |1 +
 drivers/dma/ti/k3-psil-j721s2.c   |  167 +
 

[PATCH v4 02/20] ram: k3-ddrss: lpddr4_structs_if.h: Add a pointer to ddr instance

2022-01-25 Thread Aswath Govindraju
Add a pointer to ddr instance int the lpddr4_privatedata_s structure for
supporting mutliple instances of DDR in the drivers.

Signed-off-by: Aswath Govindraju 
---
 drivers/ram/k3-ddrss/lpddr4_structs_if.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ram/k3-ddrss/lpddr4_structs_if.h 
b/drivers/ram/k3-ddrss/lpddr4_structs_if.h
index e41cbb7ff488..f2f1210c3c4e 100644
--- a/drivers/ram/k3-ddrss/lpddr4_structs_if.h
+++ b/drivers/ram/k3-ddrss/lpddr4_structs_if.h
@@ -24,6 +24,7 @@ struct lpddr4_privatedata_s {
lpddr4_infocallback infohandler;
lpddr4_ctlcallback ctlinterrupthandler;
lpddr4_phyindepcallback phyindepinterrupthandler;
+   void *ddr_instance;
 };
 
 struct lpddr4_debuginfo_s {
-- 
2.17.1



[PATCH v4 01/20] remoteproc: k3_system_controller: Support optional boot_notification channel

2022-01-25 Thread Aswath Govindraju
From: Nishanth Menon 

If there is an optional boot notification channel that an SoC uses
separate from the rx path, use the same.

Signed-off-by: Nishanth Menon 
---
 .../remoteproc/k3-system-controller.txt   |  3 +++
 drivers/remoteproc/k3_system_controller.c | 20 ++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/doc/device-tree-bindings/remoteproc/k3-system-controller.txt 
b/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
index 32f4720b0d17..33dc46812ed4 100644
--- a/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
+++ b/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
@@ -13,6 +13,9 @@ Required properties:
"rx" for Receive channel
 - mboxes:  Corresponding phandles to mailbox channels.
 
+Optional properties:
+
+- mbox-names:  "boot_notify" for Optional alternate boot notification 
channel.
 
 Example:
 
diff --git a/drivers/remoteproc/k3_system_controller.c 
b/drivers/remoteproc/k3_system_controller.c
index 89cb90207dcb..e2affe69c678 100644
--- a/drivers/remoteproc/k3_system_controller.c
+++ b/drivers/remoteproc/k3_system_controller.c
@@ -77,14 +77,18 @@ struct k3_sysctrler_desc {
  * struct k3_sysctrler_privdata - Structure representing System Controller 
data.
  * @chan_tx:   Transmit mailbox channel
  * @chan_rx:   Receive mailbox channel
+ * @chan_boot_notify:  Boot notification channel
  * @desc:  SoC description for this instance
  * @seq_nr:Counter for number of messages sent.
+ * @has_boot_notify:   Has separate boot notification channel
  */
 struct k3_sysctrler_privdata {
struct mbox_chan chan_tx;
struct mbox_chan chan_rx;
+   struct mbox_chan chan_boot_notify;
struct k3_sysctrler_desc *desc;
u32 seq_nr;
+   bool has_boot_notify;
 };
 
 static inline
@@ -223,7 +227,8 @@ static int k3_sysctrler_start(struct udevice *dev)
debug("%s(dev=%p)\n", __func__, dev);
 
/* Receive the boot notification. Note that it is sent only once. */
-   ret = mbox_recv(>chan_rx, , priv->desc->max_rx_timeout_us);
+   ret = mbox_recv(priv->has_boot_notify ? >chan_boot_notify :
+   >chan_rx, , priv->desc->max_rx_timeout_us);
if (ret) {
dev_err(dev, "%s: Boot Notification response failed. ret = 
%d\n",
__func__, ret);
@@ -272,6 +277,19 @@ static int k3_of_to_priv(struct udevice *dev,
return ret;
}
 
+   /* Some SoCs may have a optional channel for boot notification. */
+   priv->has_boot_notify = 1;
+   ret = mbox_get_by_name(dev, "boot_notify", >chan_boot_notify);
+   if (ret == -ENODATA) {
+   dev_dbg(dev, "%s: Acquiring optional Boot_notify failed. ret = 
%d. Using Rx\n",
+   __func__, ret);
+   priv->has_boot_notify = 0;
+   } else if (ret) {
+   dev_err(dev, "%s: Acquiring boot_notify channel failed. ret = 
%d\n",
+   __func__, ret);
+   return ret;
+   }
+
return 0;
 }
 
-- 
2.17.1



[PATCH 1/1] efi_loader: clean up uefi secure boot image verification logic

2022-01-25 Thread Ilias Apalodimas
We currently distinguish between signed and non signed PE/COFF executables
while trying to authenticate signatures and/or sha256 hashes in db and dbx.
That code duplication can be avoided.  When checking for sha256 hashes,
in db,  we don't really care if the image is signed or not.  The sequence
for verifying the binary can be
 1. Is the sha256 of the image in dbx,  reject the image
 2. Certification checking
  2a. Is the image signed with a certificate that's found in db and
  not in dbx
  2b. The image carries a cert which is signed by a cert in db (and
  not in dbx) and the image can be verified against the former
 3. Is the sha256 of the image in db

So weed out the 'special' case,  which is handling unsigned images.

While at it move the checking of a hash outside the certificate
verification loop which isn't really needed and check for the hash
only once.  Also allow a mix of signatures and hashes in db instead
of explicitly breaking out the SHA256 verification loop if a signature
happens to be the present before the hash.

It's worth noting that (2a) only works if the certificate is self
signed,  but that can be fixed in a following patch.

Signed-off-by: Ilias Apalodimas 
---
changes since RFC:
- added a comment indication sha256 approval is the last resort case
- reworded the commit message, based on Takahiro's proposal

 lib/efi_loader/efi_image_loader.c | 89 +++
 lib/efi_loader/efi_signature.c|  2 +-
 2 files changed, 20 insertions(+), 71 deletions(-)

diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index 255613eb72ba..90594acf9623 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -516,63 +516,17 @@ err:
 }
 
 #ifdef CONFIG_EFI_SECURE_BOOT
-/**
- * efi_image_unsigned_authenticate() - authenticate unsigned image with
- * SHA256 hash
- * @regs:  List of regions to be verified
- *
- * If an image is not signed, it doesn't have a signature. In this case,
- * its message digest is calculated and it will be compared with one of
- * hash values stored in signature databases.
- *
- * Return: true if authenticated, false if not
- */
-static bool efi_image_unsigned_authenticate(struct efi_image_regions *regs)
-{
-   struct efi_signature_store *db = NULL, *dbx = NULL;
-   bool ret = false;
-
-   dbx = efi_sigstore_parse_sigdb(L"dbx");
-   if (!dbx) {
-   EFI_PRINT("Getting signature database(dbx) failed\n");
-   goto out;
-   }
-
-   db = efi_sigstore_parse_sigdb(L"db");
-   if (!db) {
-   EFI_PRINT("Getting signature database(db) failed\n");
-   goto out;
-   }
-
-   /* try black-list first */
-   if (efi_signature_lookup_digest(regs, dbx)) {
-   EFI_PRINT("Image is not signed and its digest found in 
\"dbx\"\n");
-   goto out;
-   }
-
-   /* try white-list */
-   if (efi_signature_lookup_digest(regs, db))
-   ret = true;
-   else
-   EFI_PRINT("Image is not signed and its digest not found in 
\"db\" or \"dbx\"\n");
-
-out:
-   efi_sigstore_free(db);
-   efi_sigstore_free(dbx);
-
-   return ret;
-}
-
 /**
  * efi_image_authenticate() - verify a signature of signed image
  * @efi:   Pointer to image
  * @efi_size:  Size of @efi
  *
- * A signed image should have its signature stored in a table of its PE header.
+ * An image should have its signature stored in the image certificate table
+ *
  * So if an image is signed and only if if its signature is verified using
- * signature databases, an image is authenticated.
- * If an image is not signed, its validity is checked by using
- * efi_image_unsigned_authenticated().
+ * signature databases or if it's sha256 is found in db an image is
+ * authenticated.
+ *
  * TODO:
  * When AuditMode==0, if the image's signature is not found in
  * the authorized database, or is found in the forbidden database,
@@ -608,14 +562,7 @@ static bool efi_image_authenticate(void *efi, size_t 
efi_size)
if (!efi_image_parse(new_efi, efi_size, , ,
 _len)) {
EFI_PRINT("Parsing PE executable image failed\n");
-   goto err;
-   }
-
-   if (!wincerts) {
-   /* The image is not signed */
-   ret = efi_image_unsigned_authenticate(regs);
-
-   goto err;
+   goto out;
}
 
/*
@@ -624,18 +571,18 @@ static bool efi_image_authenticate(void *efi, size_t 
efi_size)
db = efi_sigstore_parse_sigdb(L"db");
if (!db) {
EFI_PRINT("Getting signature database(db) failed\n");
-   goto err;
+   goto out;
}
 
dbx = efi_sigstore_parse_sigdb(L"dbx");
if (!dbx) {
EFI_PRINT("Getting signature database(dbx) failed\n");
-   goto err;
+   goto out;
}
 
if 

Re: [RFC 0/2] A/B firmware update based in eMMC boot partition.

2022-01-25 Thread Wolfgang Denk
Dear Ying-Chun Liu,

In message <20220125135535.224061-1-grandp...@gmail.com> you wrote:
>
> I've implemented A/B firmware update based on eMMC hw partitions.
> Normally we have 2 boot partitions on eMMC. One is active and another
> is inactive. We can then flash the firmware to the inactive one and
> make it active.

We have been doing software updates using U-Boot scripts etc. for
many, many years.  But during that time a large number of
restrictions and shortcomings became clear.  this is why projects
like SWUpdate [1] came into life, and U-Boot supports this only with
very basic features:

- watchdog support to reset a hanging system
- boot counter to switch to an alternate boot command in case of too
  many failed boot attempts

That's all. Not more is needed, and not more should be used in
U-Boot.

I'm not sure if you know SWUpdate - if not, you should definitely
look into it.  I strongly recommend not to try to reinvent that
wheel - poorly - in U-Boot.  We have been there before, and got rid
of this approach for a pretty long list of good reasons.


[1] https://sbabic.github.io/swupdate/


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
 - Fred Brooks, Jr., _The Mythical Man Month_


[RFC 2/2] drivers: dfu: flash firmware to inactive boot area and active it

2022-01-25 Thread Ying-Chun Liu
From: "Ying-Chun Liu (PaulLiu)" 

This commit implement flash to the inactive boot partition of eMMC
when dfu_alt_info set mmcpart to "inactive". After flash to the inactive
boot partition. It will switch the active partition to the one that
just flashed.

Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Lukasz Majewski 
---
 drivers/dfu/dfu_mmc.c | 32 +---
 include/dfu.h |  1 +
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 3dab5a5f63..3c1f2018d3 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -198,6 +198,7 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
 {
int ret = -1;
+   struct mmc *mmc;
 
switch (dfu->layout) {
case DFU_RAW_ADDR:
@@ -218,6 +219,17 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
   dfu_get_layout(dfu->layout));
}
 
+   if (!ret && dfu->data.mmc.hw_partition_inactive) {
+   mmc = find_mmc_device(dfu->data.mmc.dev_num);
+   if (!mmc) {
+   pr_err("Device MMC %d - not found!",
+  dfu->data.mmc.dev_num);
+   return -ENODEV;
+   }
+
+   mmc_set_part_conf(mmc, 0, dfu->data.mmc.hw_partition, 0);
+   }
+
return ret;
 }
 
@@ -384,15 +396,29 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
dfu->data.mmc.lba_start = second_arg;
dfu->data.mmc.lba_size  = third_arg;
dfu->data.mmc.lba_blk_size  = mmc->read_bl_len;
+   dfu->data.mmc.hw_partition_inactive = false;
 
/*
 * Check for an extra entry at dfu_alt_info env variable
 * specifying the mmc HW defined partition number
 */
if (s)
-   if (!strcmp(strsep(, " "), "mmcpart"))
-   dfu->data.mmc.hw_partition =
-   simple_strtoul(s, NULL, 0);
+   if (!strcmp(strsep(, " "), "mmcpart")) {
+   if (!strcmp(s, "inactive")) {
+   u8 part_boot;
+   u8 part_target;
+
+   part_boot = 
EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+   part_target = 3 - part_boot;
+   dfu->data.mmc.hw_partition =
+   part_target;
+   dfu->data.mmc.hw_partition_inactive =
+   true;
+   } else {
+   dfu->data.mmc.hw_partition =
+   simple_strtoul(s, NULL, 0);
+   }
+   }
 
} else if (!strcmp(entity_type, "part")) {
struct disk_partition partinfo;
diff --git a/include/dfu.h b/include/dfu.h
index f6868982df..7fbcf03063 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -53,6 +53,7 @@ struct mmc_internal_data {
 
/* eMMC HW partition access */
int hw_partition;
+   bool hw_partition_inactive;
 
/* FAT/EXT */
unsigned int dev;
-- 
2.34.1



[RFC 1/2] drivers: mmc: write protect active boot area after mmc init.

2022-01-25 Thread Ying-Chun Liu
From: "Ying-Chun Liu (PaulLiu)" 

This commit implements write protection for active boot partition for
eMMC. The active boot partition is write protected, and it is still
able to write to the inactive boot partition.

Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Peng Fan 
Cc: Jaehoon Chung 
---
 drivers/mmc/Kconfig | 10 
 drivers/mmc/mmc.c   | 58 +
 2 files changed, 68 insertions(+)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index e0927ce1c9..c4bae743e6 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -100,6 +100,16 @@ config MMC_HW_PARTITIONING
  This adds a command and an API to do hardware partitioning on eMMC
  devices.
 
+config MMC_WRITE_PROTECT_ACTIVE_BOOT
+   bool "Write protection for active boot partition (eMMC)"
+   depends on MMC_HW_PARTITIONING
+   default n
+   help
+ Write protection for active boot partition when mmc initialized.
+ This option protects the active boot partition so that it cannot
+ be written. But it is still able to write to the inactive boot
+ partition.
+
 config SUPPORT_EMMC_RPMB
bool "Support eMMC replay protected memory block (RPMB)"
imply CMD_MMC_RPMB
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4d9871d69f..8620918749 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -860,6 +860,60 @@ int mmc_boot_wp(struct mmc *mmc)
return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
 }
 
+/**
+ * mmc_boot_wp_single_partition() - set write protection to a boot partition.
+ *
+ * This function sets a single boot partition to protect and leave the
+ * other partition writable.
+ *
+ * @param mmc the mmc device.
+ * @param partition 0 - first boot partition, 1 - second boot partition.
+ */
+int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
+{
+   u8 value;
+   int ret;
+
+   value = 1;
+
+   if (partition == 0) {
+   value |= 0x80;
+   ret = mmc_switch(mmc,
+EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_WP,
+value);
+   } else if (partition == 1) {
+   value |= 0x80;
+   value |= 0x02;
+   ret = mmc_switch(mmc,
+EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_WP,
+value);
+   } else {
+   ret = mmc_boot_wp(mmc);
+   }
+
+   return ret;
+}
+
+/**
+ * mmc_boot_wp_active_partition() - set write protection to active boot
+ * partition.
+ *
+ * @param mmc the mmc device.
+ */
+static int mmc_boot_wp_active_partition(struct mmc *mmc)
+{
+   u8 part;
+
+   if (mmc->part_config == MMCPART_NOAVAILABLE)
+   return -EOPNOTSUPP;
+
+   part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+
+   return mmc_boot_wp_single_partition(mmc, part - 1);
+}
+
 #if !CONFIG_IS_ENABLED(MMC_TINY)
 static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
  bool hsdowngrade)
@@ -2925,6 +2979,10 @@ static int mmc_complete_init(struct mmc *mmc)
mmc->has_init = 0;
else
mmc->has_init = 1;
+
+   if (!err && CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT))
+   mmc_boot_wp_active_partition(mmc);
+
return err;
 }
 
-- 
2.34.1



[RFC 0/2] A/B firmware update based in eMMC boot partition.

2022-01-25 Thread Ying-Chun Liu
From: "Ying-Chun Liu (PaulLiu)" 

Hi all,

I've implemented A/B firmware update based on eMMC hw partitions.
Normally we have 2 boot partitions on eMMC. One is active and another
is inactive. We can then flash the firmware to the inactive one and
make it active.

Also when booting we can write protect the current active one. And
left the inactive partition still writable.

So I make 2 commits that implements the following features:
1. Write protect "active" boot area when board init.
2. flash firmware to inactive boot area.
3. Change the inactive boot area after firmware update.

Thanks.

Ying-Chun Liu (PaulLiu) (2):
  drivers: mmc: write protect active boot area after mmc init.
  drivers: dfu: flash firmware to inactive boot area and active it

 drivers/dfu/dfu_mmc.c | 32 +---
 drivers/mmc/Kconfig   | 10 
 drivers/mmc/mmc.c | 58 +++
 include/dfu.h |  1 +
 4 files changed, 98 insertions(+), 3 deletions(-)

-- 
2.34.1



Re: [PATCH 1/1] i2c: mvtwsi: Add compatible string for allwinner, sun4i-a10-i2c

2022-01-25 Thread Jose Torres
I faced the boot failure issue when attempting to bring mainline 2022.01 to
our Kettlepop device which is a derivative of Next Thing's C.H.I.P. Pro.
Kettlepop has eMMC memory rather than NAND flash as used in C.H.I.P. Pro.
This device has a GR8 SiP which contains an R8/A13 die.
Without this patch, U-Boot will halt after DRAM detection.
Applying this patch will allow it to boot normally.
Kettlepop has a defconfig identical to mainline C.H.I.P. Pro defconfig with
MMC configuration instead of the NAND MTD stuff.

Below is a log of a failed boot:
```
U-Boot SPL 2022.01 (Jan 24 2022 - 19:48:00 +0800)
DRAM: 256 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Trying to boot from FEL


U-Boot 2022.01 (Jan 24 2022 - 19:48:00 +0800) Popcorn Computer

CPU:   Allwinner A13 (SUN5I)
Model: Source Parts Kettlepop
DRAM:  256 MiB
```


Re: [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update

2022-01-25 Thread AKASHI Takahiro
Hi Masami,

Thank you for this enhancement.

On Tue, Jan 25, 2022 at 08:31:29PM +0900, Masami Hiramatsu wrote:
> Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after
> updating firmware. Note that the machine will reboot soon after
> applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET
> flag. If there are multiple capsules and one has this flag, the
> machine may reboot while scanning the capsule files.
> You can control when the machine reboot by renaming the capsule
> file because the capsule files will be applied alphabetically.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  lib/efi_loader/efi_capsule.c |   13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 4463ae00fd..24a2a026a9 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware(
>   struct efi_firmware_management_protocol *fmp;
>   u16 *abort_reason;
>   efi_status_t ret = EFI_SUCCESS;
> + bool reset = false;
>  
>   /* sanity check */
>   if (capsule_data->header_size < sizeof(*capsule) ||
>   capsule_data->header_size >= capsule_data->capsule_image_size)
>   return EFI_INVALID_PARAMETER;
>  
> + if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) {
> + /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag */
> + if (!(capsule_data->flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET))
> + return EFI_INVALID_PARAMETER;
> + reset = true;
> + }
> +
>   capsule = (void *)capsule_data + capsule_data->header_size;
>   capsule_size = capsule_data->capsule_image_size
>   - capsule_data->header_size;
> @@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware(
>  out:
>   efi_free_pool(handles);
>  
> + if (ret == EFI_SUCCESS && reset) {
> + log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. 
> Reboot machine.\n");
> + do_reset(NULL, 0, 0, NULL);

I don't think this is the right place of calling do_reset().
Whenever you have processed any capsule file, you have to
 - delete the capsule file,
 - create/update "Capsule" and "CapsuleLast" variables, and
 - modify ESRT table
before initiating a reset.

-Takahiro Akashi

> + }
> +
>   return ret;
>  }
>  #else
> 


Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR

2022-01-25 Thread Anup Patel
On Tue, Jan 25, 2022 at 3:16 PM Bin Meng  wrote:
>
> On Tue, Jan 25, 2022 at 2:02 PM Anup Patel  wrote:
> >
> > On Tue, Jan 25, 2022 at 10:33 AM Bin Meng  wrote:
> > >
> > > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  
> > > wrote:
> > > >
> > > > Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> > > > commands even when CFI flash DT node is not present. This causes
> > > > access fault on RISC-V emulators or ISS which do not emulate CFI
> > > > flash. To handle this issue, we implement is_flash_available() for
> > > > qemu-riscv board which will return 1 only if CFI flash DT node is
> > > > present.
> > > >
> > > > Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> > > > Signed-off-by: Anup Patel 
> > > > ---
> > > >  board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> > > >  1 file changed, 17 insertions(+)
> > > >
> > > > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
> > > > b/board/emulation/qemu-riscv/qemu-riscv.c
> > > > index b0d9dd59b1..cd02dae1ab 100644
> > > > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > > > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > > > @@ -8,6 +8,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -16,6 +17,22 @@
> > > >
> > > >  DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > > +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> > > > +int is_flash_available(void)
> > > > +{
> > > > +   if (IS_ENABLED(CONFIG_OF_SEPARATE) || 
> > > > IS_ENABLED(CONFIG_OF_BOARD)) {
> > >
> > > Why is this if statement needed?
> > >
> > > All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
> > > OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.
> >
> > I added the if statement for the case if someone disables CONFIG_OF_BOARD
> > but I can remove it if you insist.
> >
>
> I see. But I if we give a dtb to QEMU without using CONFIG_OF_BOARD,
> the dtb may still contain a node for flash so the logic you added is
> still needed.
>
> So I think you can just remove the if statement.

Okay, I will remove the "if ()" check.

>
> Also instead of using fdt_node_offset_by_compatible API please use
> ofnode_device_is_compatible.

Sure, I will try ofnode_device_is_compatible().

>
> Regards,
> Bin

Regards,
Anup


Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver

2022-01-25 Thread Anup Patel
On Tue, Jan 25, 2022 at 2:46 PM Bin Meng  wrote:
>
> On Tue, Jan 25, 2022 at 2:00 PM Anup Patel  wrote:
> >
> > On Tue, Jan 25, 2022 at 10:22 AM Bin Meng  wrote:
> > >
> > > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  
> > > wrote:
> > > >
> > > > Quite a few RISC-V emulators and ISS (including Spike) have host
> > > > transfer interface (HTIF) based console. This patch adds HTIF
> > > > based console driver for RISC-V platforms which depends totally
> > > > on DT node for HTIF register base address.
> > > >
> > > > Signed-off-by: Anup Patel 
> > > > Reviewed-by: Philipp Tomsich 
> > > > ---
> > > >  drivers/serial/Kconfig   |   8 ++
> > > >  drivers/serial/Makefile  |   1 +
> > > >  drivers/serial/serial_htif.c | 178 +++
> > > >  3 files changed, 187 insertions(+)
> > > >  create mode 100644 drivers/serial/serial_htif.c
> > > >
> > > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > > index 6c8fdda9a0..345d1881f5 100644
> > > > --- a/drivers/serial/Kconfig
> > > > +++ b/drivers/serial/Kconfig
> > > > @@ -866,6 +866,14 @@ config PXA_SERIAL
> > > >   If you have a machine based on a Marvell XScale PXA2xx CPU you
> > > >   can enable its onboard serial ports by enabling this option.
> > > >
> > > > +config HTIF_CONSOLE
> > > > +   bool "RISC-V HTIF console support"
> > > > +   depends on DM_SERIAL && 64BIT
> > >
> > > Does this driver not work on 32-bit?
> >
> > Only putc() works but getc() does not work on 32-bit. Same issue
> > is there with OpenSBI and BBL as well. That's why I have restricted
> > this driver to 64-bit only.
> >
>
> I don't get it. Is this a QEMU riscv32 bug?

It's a bug in the HTIF device itself. There is no documentation of
HTIF as well. All implementations (including QEMU spike) simply
follow how Spike ISS implements HTIF.

In other words, HTIF is yet another undocumented device in
RISC-V world.

Regards,
Anup


[PATCH 2/2] mkeficapsule: Support "--flags reset" option

2022-01-25 Thread Masami Hiramatsu
Support "--flags reset" option to set the CAPSULE_FLAGS_INITIATE_RESET
flag to capsule header.

Signed-off-by: Masami Hiramatsu 
---
 tools/mkeficapsule.c |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 4995ba4e0c..ca3a1c77ad 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -44,6 +44,7 @@ static struct option options[] = {
{"raw", required_argument, NULL, 'r'},
{"index", required_argument, NULL, 'i'},
{"instance", required_argument, NULL, 'I'},
+   {"flags", required_argument, NULL, 'F' },
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
 };
@@ -57,12 +58,13 @@ static void print_usage(void)
   "\t-r, --rawnew raw image file\n"
   "\t-i, --index  update image index\n"
   "\t-I, --instanceupdate hardware instance\n"
+  "\t-F, --flags  set capsule flags (support only 
\"reset\")\n"
   "\t-h, --help  print a help message\n",
   tool_name);
 }
 
 static int create_fwbin(char *path, char *bin, efi_guid_t *guid,
-   unsigned long index, unsigned long instance)
+   unsigned long index, unsigned long instance, u32 flags)
 {
struct efi_capsule_header header;
struct efi_firmware_management_capsule_header capsule;
@@ -101,7 +103,7 @@ static int create_fwbin(char *path, char *bin, efi_guid_t 
*guid,
header.capsule_guid = efi_guid_fm_capsule;
header.header_size = sizeof(header);
/* TODO: The current implementation ignores flags */
-   header.flags = CAPSULE_FLAGS_PERSIST_ACROSS_RESET;
+   header.flags = CAPSULE_FLAGS_PERSIST_ACROSS_RESET | flags;
header.capsule_image_size = sizeof(header)
+ sizeof(capsule) + sizeof(u64)
+ sizeof(image)
@@ -171,6 +173,14 @@ err_1:
return -1;
 }
 
+int decode_capsule_flags(const char *flagstr, u32 *flags)
+{
+   if (strcmp(flagstr, "reset"))
+   return -EINVAL;
+   *flags = CAPSULE_FLAGS_INITIATE_RESET;
+   return 0;
+}
+
 /*
  * Usage:
  *   $ mkeficapsule -f  
@@ -178,6 +188,7 @@ err_1:
 int main(int argc, char **argv)
 {
char *file;
+   u32 flags;
efi_guid_t *guid;
unsigned long index, instance;
int c, idx;
@@ -186,8 +197,9 @@ int main(int argc, char **argv)
guid = NULL;
index = 0;
instance = 0;
+   flags = 0;
for (;;) {
-   c = getopt_long(argc, argv, "f:r:i:I:v:h", options, );
+   c = getopt_long(argc, argv, "f:r:i:I:v:F:h", options, );
if (c == -1)
break;
 
@@ -214,6 +226,12 @@ int main(int argc, char **argv)
case 'I':
instance = strtoul(optarg, NULL, 0);
break;
+   case 'F':
+   if (decode_capsule_flags(optarg, ) < 0) {
+   printf("Unsupported flags %s\n", optarg);
+   return -1;
+   }
+   break;
case 'h':
print_usage();
return 0;
@@ -232,7 +250,7 @@ int main(int argc, char **argv)
exit(EXIT_SUCCESS);
}
 
-   if (create_fwbin(argv[optind], file, guid, index, instance)
+   if (create_fwbin(argv[optind], file, guid, index, instance, flags)
< 0) {
printf("Creating firmware capsule failed\n");
exit(EXIT_FAILURE);



[PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update

2022-01-25 Thread Masami Hiramatsu
Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after
updating firmware. Note that the machine will reboot soon after
applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET
flag. If there are multiple capsules and one has this flag, the
machine may reboot while scanning the capsule files.
You can control when the machine reboot by renaming the capsule
file because the capsule files will be applied alphabetically.

Signed-off-by: Masami Hiramatsu 
---
 lib/efi_loader/efi_capsule.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 4463ae00fd..24a2a026a9 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware(
struct efi_firmware_management_protocol *fmp;
u16 *abort_reason;
efi_status_t ret = EFI_SUCCESS;
+   bool reset = false;
 
/* sanity check */
if (capsule_data->header_size < sizeof(*capsule) ||
capsule_data->header_size >= capsule_data->capsule_image_size)
return EFI_INVALID_PARAMETER;
 
+   if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) {
+   /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag */
+   if (!(capsule_data->flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET))
+   return EFI_INVALID_PARAMETER;
+   reset = true;
+   }
+
capsule = (void *)capsule_data + capsule_data->header_size;
capsule_size = capsule_data->capsule_image_size
- capsule_data->header_size;
@@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware(
 out:
efi_free_pool(handles);
 
+   if (ret == EFI_SUCCESS && reset) {
+   log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. 
Reboot machine.\n");
+   do_reset(NULL, 0, 0, NULL);
+   }
+
return ret;
 }
 #else



[PATCH 0/2] EFI: Add CAPSULE_FLAG_INITIATE_RESET support

2022-01-25 Thread Masami Hiramatsu
Hi,

This is the patchset for adding CAPSULE_FLAG_INITIATE_RESET
support to EFU capsule support, according to Takahiro's
comment.

The first patch is the core patch to add supporting the
CAPSULE_FLAG_INITIATE_RESET. The system reset soon after
applying the capsule file which has this flag. The rest of
capsule files on disk will be applied after reboot.
The second one adding "--flags reset" option to mkeficapsule
tool. This might better be rebased on top of Takahiro's work,
but in this version I made this series on top of the latest
master branch.

Thank you,

---

Masami Hiramatsu (2):
  EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update
  mkeficapsule: Support "--flags reset" option


 lib/efi_loader/efi_capsule.c |   13 +
 tools/mkeficapsule.c |   26 ++
 2 files changed, 35 insertions(+), 4 deletions(-)

--
Masami Hiramatsu 


Re: [PATCH] arm64: dts: imx8mm: Add missing MX8MM_IOMUXC_NAND_READY_B_SD3_RESET_B

2022-01-25 Thread Fabio Estevam
Hi Marek,

On Mon, Jan 24, 2022 at 11:49 PM Marek Vasut  wrote:
>
> The i.MX8M Mini Application Processor Reference Manual, Rev. 3, 11/2020
> documents AF MX8MM_IOMUXC_NAND_READY_B_SD3_RESET_B , add it into the
> pinmux tables.
>
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 

Reviewed-by: Fabio Estevam 


Re: [PATCH] regulator: bd718x7: Bypass bogus warnings

2022-01-25 Thread Vaittinen, Matti
Hi dee Ho peeps!

On 1/25/22 04:46, Marek Vasut wrote:
> When regulator consumer attempts to set enabled DVS regulator voltage,
> the driver aborts with "Only DVS bucks can be changed when enabled".
> In case the regulator is already set to specified voltage, do nothing
> instead of failing outright.
> 
> When regulator consumer attempts to set enables regulator which cannot
> be controlled because it is already always enabled, the driver aborts
> with -EINVAL. Again, do nothing in such case and return 0, because the
> request is really fulfilled, the regulator is enabled.
>

I think this change makes sense. But at the same time there are risks.

I originally wrote this driver for executing some simple tests with the 
PMIC w/o loading an OS to control it. As a result, this driver uses 
static regulator configuration and assumes the run-states and things 
like whether to enable SW control for regulator ON/OFF.

What I am somewhat worried about is potential use together with full OS. 
For example at the current Linux driver for BD71837/BD71847 these 
assumptions are no longer enforced - whether to keep hardware-control 
for regulators or if the voltages are actually scaled by external 
feed-back connections can now be defined for OS via device-tree.

I am not sure what would be the best approach. We could add all the 
functionality and device-tree parsing that is done by the Linux driver - 
or we could remove all constraints/assumptions and leave sanity checks 
for users - which for sure can risk the SOC to not boot unless power to 
PMIC is cut (in practice this can mean removing/completely draining a 
battery).

To tell the truth - I have no idea where this driver is nowadays used - 
or if it is - so I can't really say what would be the sane thing to do :)


> Signed-off-by: Marek Vasut 
> Cc: Matti Vaittinen 
> ---
>   drivers/power/regulator/bd71837.c | 69 ---
>   1 file changed, 36 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/power/regulator/bd71837.c 
> b/drivers/power/regulator/bd71837.c
> index 74011d62985..d4f8da80ad7 100644
> --- a/drivers/power/regulator/bd71837.c
> +++ b/drivers/power/regulator/bd71837.c
> @@ -306,7 +306,7 @@ static int bd71837_set_enable(struct udevice *dev, bool 
> enable)
>* reseted to snvs state. Hence we can't set the state here.
>*/
>   if (plat->enablemask == HW_STATE_CONTROL)

The HW_STATE_CONTROL flag is hard-coded based on assumed use-case for 
the power-rails and assumed reset-target. (Eg, it's not required to 
reset to SNVS state - in which case any of the power-rails can be under 
SW control. OTOH, it may be leaving power rail to the HW control is 
requested for any power rail regardless of the SNVS / boot-criticality 
in order to force certain output state at STBY. So simple hard-coding 
the HW_STATE_CONTROL may not work well with the OS configuration.

> - return -EINVAL;
> + return enable ? 0 : -EINVAL;
>   
>   if (enable)
>   val = plat->enablemask;
> @@ -315,6 +315,38 @@ static int bd71837_set_enable(struct udevice *dev, bool 
> enable)
>  val);
>   }
>   
> +static int bd71837_get_value(struct udevice *dev)
> +{
> + unsigned int reg, range;
> + unsigned int tmp;
> + struct bd71837_plat *plat = dev_get_plat(dev);
> + int i;
> +
> + reg = pmic_reg_read(dev->parent, plat->volt_reg);
> + if (((int)reg) < 0)
> + return reg;
> +
> + range = reg & plat->rangemask;
> +
> + reg &= plat->volt_mask;
> + reg >>= ffs(plat->volt_mask) - 1;
> +
> + for (i = 0; i < plat->numranges; i++) {
> + struct bd71837_vrange *r = >ranges[i];
> +
> + if (plat->rangemask && ((plat->rangemask & range) !=
> + r->rangeval))
> + continue;
> +
> + if (!vrange_find_value(r, reg, ))
> + return tmp;
> + }
> +
> + pr_err("Unknown voltage value read from pmic\n");
> +
> + return -EINVAL;
> +}
> +
>   static int bd71837_set_value(struct udevice *dev, int uvolt)
>   {
>   unsigned int sel;
> @@ -330,6 +362,9 @@ static int bd71837_set_value(struct udevice *dev, int 
> uvolt)
>*/
>   if (!plat->dvs)
>   if (bd71837_get_enable(dev)) {
> + /* If the value is already set, skip the warning. */
> + if (bd71837_get_value(dev) == uvolt)
> + return 0;

I believe this fix is always correct - thanks Marek!

As a summary - no objections to the changes, just a word of warning for 
users of this driver that there might be more than this to do...

Best Regards
-- Matti

-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~


[PATCH] scripts: Makefile: also clean subdir dtc

2022-01-25 Thread Philippe Reynes
Since commit 93b196532254 ("Makefile: Only build dtc if needed"),
the sub directory scripts/dtc is never cleaned.
Adds the directory dtc to subdir to always clean it.

Signed-off-by: Philippe Reynes 
---
 scripts/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index cfe9fef804..8731e6cecd 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -9,4 +9,4 @@ hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c
 always := $(hostprogs-y)
 
 # Let clean descend into subdirs
-subdir-+= basic kconfig
+subdir-+= basic kconfig dtc
-- 
2.17.1



[RESEND PATCH] arm: kirkwood: Pogoplug V4 : Use Marvell network PHY driver

2022-01-25 Thread Tony Dinh
The Pogoplug V4 board has the network chip Marvell 88E1116R. So to
properly configure the network, enable CONFIG_PHY_MARVELL to activate
the compatible driver M88E1118R.

- This patch depends on the series:
https://patchwork.ozlabs.org/project/uboot/patch/20220124061712.28316-2-mibo...@gmail.com/

Signed-off-by: Tony Dinh 
---

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

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index 5490067b9e..1cf409c834 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -62,6 +62,7 @@ CONFIG_KIRKWOOD_GPIO=y
 CONFIG_MVEBU_MMC=y
 CONFIG_MTD=y
 CONFIG_MTD_RAW_NAND=y
+CONFIG_PHY_MARVELL=y
 CONFIG_DM_ETH=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
-- 
2.30.2



[PATCH] arm: kirkwood: Pogoplug V4 : Use Marvel network PHY driver

2022-01-25 Thread Tony Dinh
The Pogoplug V4 board has the network chip Marvell 88E1118R. So to
properly configure the network, enable CONFIG_PHY_MARVELL to activate
the driver M88E1118R.

- This patch depends on the series:
https://patchwork.ozlabs.org/project/uboot/patch/20220124061712.28316-2-mibo...@gmail.com/

Signed-off-by: Tony Dinh 
---

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

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index 5490067b9e..1cf409c834 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -62,6 +62,7 @@ CONFIG_KIRKWOOD_GPIO=y
 CONFIG_MVEBU_MMC=y
 CONFIG_MTD=y
 CONFIG_MTD_RAW_NAND=y
+CONFIG_PHY_MARVELL=y
 CONFIG_DM_ETH=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
-- 
2.30.2



Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR

2022-01-25 Thread Bin Meng
On Tue, Jan 25, 2022 at 2:02 PM Anup Patel  wrote:
>
> On Tue, Jan 25, 2022 at 10:33 AM Bin Meng  wrote:
> >
> > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
> > >
> > > Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> > > commands even when CFI flash DT node is not present. This causes
> > > access fault on RISC-V emulators or ISS which do not emulate CFI
> > > flash. To handle this issue, we implement is_flash_available() for
> > > qemu-riscv board which will return 1 only if CFI flash DT node is
> > > present.
> > >
> > > Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> > > Signed-off-by: Anup Patel 
> > > ---
> > >  board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> > >  1 file changed, 17 insertions(+)
> > >
> > > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
> > > b/board/emulation/qemu-riscv/qemu-riscv.c
> > > index b0d9dd59b1..cd02dae1ab 100644
> > > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > > @@ -8,6 +8,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -16,6 +17,22 @@
> > >
> > >  DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> > > +int is_flash_available(void)
> > > +{
> > > +   if (IS_ENABLED(CONFIG_OF_SEPARATE) || 
> > > IS_ENABLED(CONFIG_OF_BOARD)) {
> >
> > Why is this if statement needed?
> >
> > All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
> > OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.
>
> I added the if statement for the case if someone disables CONFIG_OF_BOARD
> but I can remove it if you insist.
>

I see. But I if we give a dtb to QEMU without using CONFIG_OF_BOARD,
the dtb may still contain a node for flash so the logic you added is
still needed.

So I think you can just remove the if statement.

Also instead of using fdt_node_offset_by_compatible API please use
ofnode_device_is_compatible.

Regards,
Bin


Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver

2022-01-25 Thread Bin Meng
On Tue, Jan 25, 2022 at 2:00 PM Anup Patel  wrote:
>
> On Tue, Jan 25, 2022 at 10:22 AM Bin Meng  wrote:
> >
> > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
> > >
> > > Quite a few RISC-V emulators and ISS (including Spike) have host
> > > transfer interface (HTIF) based console. This patch adds HTIF
> > > based console driver for RISC-V platforms which depends totally
> > > on DT node for HTIF register base address.
> > >
> > > Signed-off-by: Anup Patel 
> > > Reviewed-by: Philipp Tomsich 
> > > ---
> > >  drivers/serial/Kconfig   |   8 ++
> > >  drivers/serial/Makefile  |   1 +
> > >  drivers/serial/serial_htif.c | 178 +++
> > >  3 files changed, 187 insertions(+)
> > >  create mode 100644 drivers/serial/serial_htif.c
> > >
> > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > index 6c8fdda9a0..345d1881f5 100644
> > > --- a/drivers/serial/Kconfig
> > > +++ b/drivers/serial/Kconfig
> > > @@ -866,6 +866,14 @@ config PXA_SERIAL
> > >   If you have a machine based on a Marvell XScale PXA2xx CPU you
> > >   can enable its onboard serial ports by enabling this option.
> > >
> > > +config HTIF_CONSOLE
> > > +   bool "RISC-V HTIF console support"
> > > +   depends on DM_SERIAL && 64BIT
> >
> > Does this driver not work on 32-bit?
>
> Only putc() works but getc() does not work on 32-bit. Same issue
> is there with OpenSBI and BBL as well. That's why I have restricted
> this driver to 64-bit only.
>

I don't get it. Is this a QEMU riscv32 bug?

Regards,
Bin


Re: [PATCH V3] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn

2022-01-25 Thread Marcel Ziswiler
On Mon, 2022-01-17 at 18:21 -0600, Adam Ford wrote:
> The imx8mm and imx8mn appear compatible with imx7d-usb
> flags in the OTG driver.  If the dr_mode is defined as
> host or peripheral, the device appears to operate correctly,
> however the auto host/peripheral detection results in an error.
> 
> The solution isn't just adding checks for imx8mm and imx8mn to
> the check for imx7, because the USB clock needs to be running
> to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
> 
> Marek requested that I not enable the clocks in ehci_usb_of_to_plat,
> so I modified that function to return an unknown state if the
> device tree does not explicitly state whether it is a host
> or a peripheral.
> 
> When the driver probes, it looks to see if it's in the unknown
> state, and only then will it read the register to auto-detect.
> 
> Signed-off-by: Adam Ford 
> ---
> V3:  Keep ehci_usb_of_to_plat but add the ability to return
>  and unknown state instead of reading the register.
>  If the probe determines the states is unknown, it will
>  query the register after the clocks have been enabled.
>  Because of the slight behavior change, I removed any
>  review or tested tags.
> 
> V2:  Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
>  from the probe after the clocks are enabled, but before
>  the data is needed.
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 1bd6147c76..cf44e53ff7 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -543,7 +543,7 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> plat->init_type = USB_INIT_DEVICE;
> else
> plat->init_type = USB_INIT_HOST;
> -   } else if (is_mx7()) {
> +   } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
> phy_status = (void __iomem *)(addr +
>   USBNC_PHY_STATUS_OFFSET);
> val = readl(phy_status);
> @@ -573,9 +573,8 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
> case USB_DR_MODE_PERIPHERAL:
> plat->init_type = USB_INIT_DEVICE;
> break;
> -   case USB_DR_MODE_OTG:
> -   case USB_DR_MODE_UNKNOWN:
> -   return ehci_usb_phy_mode(dev);
> +   default:
> +   plat->init_type = USB_INIT_UNKNOWN;
> };
>  
> return 0;
> @@ -677,6 +676,20 @@ static int ehci_usb_probe(struct udevice *dev)
> mdelay(1);
>  #endif
>  
> +   /*
> +    * If the device tree didn't specify host or device,
> +    * the default is USB_INIT_UNKNOWN, so we need to check
> +    * the register. For imx8mm and imx8mn, the clocks need to be
> +    * running first, so we defer the check until they are.
> +    */
> +   if (priv->init_type == USB_INIT_UNKNOWN) {
> +   ret = ehci_usb_phy_mode(dev);
> +   if (ret)
> +   goto err_clk;

Hm, unfortunately, that label is gated by an ifdef leading to the following on 
colibri_imx7:

drivers/usb/host/ehci-mx6.c: In function ‘ehci_usb_probe’:
drivers/usb/host/ehci-mx6.c:688:4: error: label ‘err_clk’ used but not defined
  688 |goto err_clk;
  |^~~~
make[1]: *** [scripts/Makefile.build:254: drivers/usb/host/ehci-mx6.o] Error 1

I have to admit that maybe we should indeed run it with DM_REGULATOR but that 
won't change anything on this
issue. I guess one should really not have any gotos to a label err_clk being 
ifdefed from somewhere not
ifdefed.

> +   else
> +   priv->init_type = plat->init_type;
> +   }
> +
>  #if CONFIG_IS_ENABLED(DM_REGULATOR)
> ret = device_get_supply_regulator(dev, "vbus-supply",
>   >vbus_supply);
> diff --git a/include/usb.h b/include/usb.h
> index b3851fdb4f..47d738a786 100644
> --- a/include/usb.h
> +++ b/include/usb.h
> @@ -163,7 +163,8 @@ struct int_queue;
>   */
>  enum usb_init_type {
> USB_INIT_HOST,
> -   USB_INIT_DEVICE
> +   USB_INIT_DEVICE,
> +   USB_INIT_UNKNOWN,
>  };
>  
>  /**


  1   2   >