Re: [PATCH 00/30] Fix issues with QSPI and OSPI compare failures

[Michal Simek]

On 12/6/23 06:29, Tejas Bhumkar wrote:

A set of patches has been developed to resolve concerns regarding
data integrity failures in QSPI and OSPI for the Versal, Versal NET,
Zynq, and ZynqMP platforms.

The series has undergone testing with flashes on the default setup,
and comprehensive testing is currently underway to test the series
with all available flash parts.

These patches are built upon the v5 series, which can be found at
the following link:
https://lore.kernel.org/all/20231201031839.239567-1-venkatesh.abbar...@amd.com/

Algapally Santosh Sagar (1):
   mtd: spi-nor-ids: Add support for W25Q02NW

Ashok Reddy Soma (10):
   mtd: spi-nor: Enable mt35xu512aba_fixups for all mt35xx flashes
   mtd: spi-nor: Add support for cross die read in dual flash
 configuration
   mtd: spi-nor: Enable DTR octal flash program
   mtd: spi-nor: Send write disable cmd after every write enable
   mtd: spi-nor: Check SNOR_F_IO_MODE_EN_VOLATILE only if SFDP is enabled
   spi: cadence_qspi: Set tshsl_ns to at least one sclk_ns
   spi: cadence_qspi: Clean up registers in init
   spi: cadence_qspi: Initialize read and write watermark registers
   spi: cadence_qspi: Enable ECO bit for higher frequencies
   spi: cadence_qspi: Write aligned byte length to ahbbase

T Karthik Reddy (9):
   mtd: spi-nor: Add config to enable flash DTR
   mtd: spi-nor-core: Set dummy buswidth equal to data buswidth
   spi: mtd: Use split reads if multi-die flag is set
   mtd: spi-nor: program quad enable bit for winbond flashes
   spi: cadence_qspi: Setup ddr mode in cadence qspi driver
   spi: cadence-qspi: Switch SDR/DTR using SPI_FLASH_DTR_ENABLE config
   spi: cadence_ospi_versal: ospi ddr changes in cadence ospi versal
 driver
   spi: cadence_qspi: Add spi mem dtr support ops
   mtd: spi-nor: Add block protection support for micron flashes

Tejas Bhumkar (5):
   arm64: versal: Enable defconfig for Micron octal flashes
   mtd: spi-nor: Update erase operation function
   spi: cadence_qspi: Fix versal ospi indirect write timed out issue
   arm64: versal: Enable soft reset support for xspi flashes
   arm64: versal: Enable octal DTR mode

Venkatesh Yadav Abbarapu (5):
   mtd: spi-nor: Update block protection flags for flash parts
   mtd: spi-nor: Add support for locking on Macronix nor flashes
   mtd: spi-nor: Add support for locking on ISSI nor flashes
   mtd: spi-nor: Add support for locking on GIGADEVICE nor flashes
   mtd: spi-nor: Add support for locking on Spansion nor flashes

  configs/xilinx_versal_virt_defconfig |4 +
  drivers/mtd/spi/Kconfig  |7 +
  drivers/mtd/spi/sf_internal.h|8 +
  drivers/mtd/spi/spi-nor-core.c   | 2028 +++---
  drivers/mtd/spi/spi-nor-ids.c|   40 +-
  drivers/spi/cadence_ospi_versal.c|   77 +-
  drivers/spi/cadence_qspi.c   |  403 -
  drivers/spi/cadence_qspi.h   |   71 +
  drivers/spi/cadence_qspi_apb.c   |  107 +-
  include/linux/mtd/spi-nor.h  |   22 +
  include/spi.h|4 +-
  11 files changed, 2545 insertions(+), 226 deletions(-)



Series it not send as one thread which confuse b4 and not able to get it from 
lore. Can you please resend it with RESEND tag but with --thread enabled?


Thanks,
Michal


 b4 am -l 20231206053353.3745918-1-tejas.arvind.bhum...@amd.com
Grabbing thread from 
lore.kernel.org/all/20231206053353.3745918-1-tejas.arvind.bhumkar%40amd.com/t.mbox.gz

Analyzing 10 messages in the thread
Checking attestation on all messages, may take a moment...
---
  ERROR: missing [1/30]!
  ERROR: missing [2/30]!
  ERROR: missing [3/30]!
  ERROR: missing [4/30]!
  ERROR: missing [5/30]!
  ERROR: missing [6/30]!
  ERROR: missing [7/30]!
  ERROR: missing [8/30]!
  ERROR: missing [9/30]!
  ✓ [PATCH 10/30] mtd: spi-nor: program quad enable bit for winbond flashes
✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-1-tejas.arvind.bhum...@amd.com

  ✓ [PATCH 11/30] mtd: spi-nor: Send write disable cmd after every write enable
✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-2-tejas.arvind.bhum...@amd.com

  ✓ [PATCH 12/30] mtd: spi-nor: Update erase operation function
✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-3-tejas.arvind.bhum...@amd.com
  ✓ [PATCH 13/30] mtd: spi-nor: Check SNOR_F_IO_MODE_EN_VOLATILE only if SFDP 
is enabled

✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-4-tejas.arvind.bhum...@amd.com

  ✓ [PATCH 14/30] spi: cadence_qspi: Setup ddr mode in cadence qspi driver
✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-5-tejas.arvind.bhum...@amd.com
  ✓ [PATCH 15/30] spi: cadence-qspi: Switch SDR/DTR using SPI_FLASH_DTR_ENABLE 
config

✓ Signed: DKIM/amd.com
+ Link: 
https://lore.kernel.org/r/20231206053353.3745918-6-tejas.arvind.bhum...@amd.com
  ✓ [PATCH 

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Soeren Moch]

On 05.12.23 21:00, Maxim Uvarov wrote:

On Wed, 6 Dec 2023 at 00:25, Soeren Moch  wrote:

On 05.12.23 17:25, Maxim Uvarov wrote:

On Tue, 5 Dec 2023 at 21:49, Soeren Moch  wrote:

On 05.12.23 14:15, Maxim Uvarov wrote:

I think I solved the size issue on all the boards.

Key changes:
1. remove compilation of original ping.c and tftp.c (tftp
had also server code, so I will partially bring it back.)

Interesting.
@Tom: Is there other server code in u-boot, that is enabled
by default (and can be used to reclaim code space)?
Fur sure I do not need u-boot to act as server for tftp (maye
nfs, others).


Maybe I need to be more clear about this. reference to code from
tftp.c and ping.c exist in net.c, test/image/spl_load_net.c,
test.dm/dsa.c , test/dm/eth.c.
And even if that code is not used (replaced with lwip calls to
the same commands in my case) it adds additional size. Even
enabled LTO does not see
direct difference.

So 'server code' does not mean u-boot acting as network server,
you mean this code is referenced by something else? And things in
test do increase image size?


This was my question to understand possible options to save space.





2. LTO=y
3. CONFIG_LOGLEVEL=3 instead of 4.
4. CONFIG_CMD_DATE is not set
5. CONFIG_CMD_LICENSE is not set
6. CONFIG_CMD_PING (if 1-6 did not help).

And these changes were enough for CI tagrets to build.
I also tested that Raspberry PI 4B works fine (dhcp, ping).
Looking for other boards to test.

For example for this tbs2910 board changes are:

Disabling CMD_DATE is unfortunate. This can help to debug RTC
problems (already used it for this purpose).
And, if we are that close to the size limit, than maybe we
can get away for this series, but for sure will run into
trouble for every other small change to u-boot core/driver code.

Regards,
Soeren


The problem is that for many targets the limit is 1MB.

For tbs2910 it is 383kBytes. And there was plenty of free space
when I introduced mainline u-boot support. But yes, space got
tighter over time.


Hm,
orig:
-rw-r--r-- 1 uboot uboot 371K Dec  5 19:54 u-boot.bin
lwip:
-rw-r--r-- 1 uboot uboot 380K Dec  5 19:55 u-boot.bin

Then if I just enable CMD_DATE:
u-boot.imx exceeds file size limit:
  limit:  0x5fc00 bytes
  actual: 0x60c00 bytes
  excess: 0x1000 bytes
make: *** [Makefile:1240: u-boot.imx] Error 1
make: *** Deleting file 'u-boot.imx'
uboot@3eebd85985c8:~/uboot-size$ ls -lh u-boot.bin
-rw-r--r-- 1 uboot uboot 382K Dec  5 19:58 u-boot.bin

So limit for your board is:
(gdb) p 0x5fc00/1024
$1 = 383

383k. Where do you see the space?

Here I do not understand what you want to ask.

As I wrote earlier, yes, tbs2910 limit is 383k, for u-boot.imx, the
number you tried to change in this patch to 408k, but this change is not
possible.

Without your changes there is some space left (not as much as 2014 when
I introduced tbs2910 support in u-boot), but enough to make further
u-boot development with unavoidable small image size increases possible.
(size of v2024.01-rc4 u-boot.imx for tbs2910 is 375k).

Regards,
Soeren


BR,
Maxim.


U-Boot in some minimal configuration is about 500kb. But U-boot
with EFI, USB, Eth drivers, MMC, RTC, and all the commands is
900+ kb and very close to 1MB. Most of the new features are
enabled by default.

No. Tom does a very good job to ensure that there is no (not much)
additional space required for unrelated boards that do not need
new features.

I.e. they do not exist in _defconfig and appear in the resulting
.config automatically.  I would say that for some small targets
things like EFI, Secure boot, TPM, Updates and many others are
not needed. But if new features will appear by default very soon
we will see limits.

New features will not be enabled for old space constrained boards.
In your series you did not offer to keep the old implementation
instead, this is different and the reason why we discuss image
size constraints.

Regards,
Soeren


BR,
Maxim.



--- a/configs/tbs2910_defconfig
+++ b/configs/tbs2910_defconfig
@@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
 CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
 CONFIG_BOARD_SIZE_LIMIT=392192
+CONFIG_TIMESTAMP=y (this was added by savedefconfig)
 # CONFIG_BOOTSTD is not set
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOOTDELAY=3
@@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run
bootcmd_up1; then run bootcmd_up2; else r
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
 CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"

Re: [PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Wed, 6 Dec 2023 at 09:24, Simon Glass  wrote:
>
> Hi Sumit,
>
> On Tue, 5 Dec 2023 at 00:44, Sumit Garg  wrote:
> >
> > Hi Simon,
> >
> > On Tue, 5 Dec 2023 at 06:22, Simon Glass  wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
> > > >
> > > > Hi Caleb,
> > > >
> > > > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly 
> > > >  wrote:
> > > > >
> > > > > Historically, Qualcomm boards in U-Boot have all had their own
> > > > > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, 
> > > > > their
> > > > > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > > > > devicetree with little/no compatibility with upstream DT.
> > > > >
> > > > > This series makes a few final prepatory changes, and then replaces
> > > > > almost all of the board specific code with generic alternatives. The 
> > > > > end
> > > > > result is that all Qualcomm boards both current and future (with the
> > > > > exception of the db410c and db820c) can be supported by a single 
> > > > > U-Boot
> > > > > binary by just providing the correct DT. New boards can be added 
> > > > > without
> > > > > introducing any addition mach/ or board/ code or config options.
> > > > >
> > > > > Due to the nature of this change, the patch ("mach-snapdragon:
> > > > > generalise board support") has become pretty big, I tried a few
> > > > > different ways to represent this in git history, but the other methods
> > > > > (e.g. adding a stub "generic" target and removing it again) were more
> > > > > confusing and made for much messier git history. The current patch is
> > > > > mostly atomic, but requires regenerating the config.
> > > > >
> > > > > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > > > > this is dropped in favour of a adding a new vbus-supply property to 
> > > > > the
> > > > > dwc3-generic driver. This will also be used by the dragonboard845c in 
> > > > > a
> > > > > future patch. This handles the common case of a board requiring some
> > > > > regulator be enabled for USB host mode.
> > > > >
> > > >
> > > > Thanks for your work. It is a good step towards a generalized u-boot
> > > > on Qcom platforms. Although I would like to give it an in-depth
> > > > review, I have a common discussion point about DT, see below.
> > > >
> > > > > A more detailed description of the changes is below.
> > > > >
> > > > > == Memory map ==
> > > > >
> > > > > The memory map was historically hardcoded into U-Boot, this meant that
> > > > > U-Boot had to be built for a specific variant of a device. This is
> > > > > changed to instead read the memory map from the DT /memory node.
> > > > >
> > > > > Additionally, most boards mapped addresss 0x0 as valid, as a result 
> > > > > if a
> > > > > null pointer access happens then it will cause a bus stall (and board
> > > > > hang). This is fixed so that null pointer accesses will now correctly
> > > > > throw an exception.
> > > > >
> > > > > == DT loading ==
> > > > >
> > > > > Previously, boards used the FDT blob embedded into U-Boot (via
> > > > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > > > > bootloader, so we can instead rely on the first-stage bootloader to
> > > > > populate some useful FDT properties for us (notably the /memory node 
> > > > > and
> > > > > KASLR seed) and fetch the DTB that it provides. Combined with the 
> > > > > memory
> > > > > map changes above, this let's us entirely avoid configuring the memory
> > > > > map explicitly.
> > > >
> > > > Since with this change, we don't need to embed FDT blob in the u-boot
> > > > binary, so I was thinking if we really need to import DTs from Linux
> > > > for different platforms and then play a catchup game?
> > > >
> > > > IMO, the build command would look like following if we import
> > > > pre-built FDT blob from Linux:
> > > >
> > > > - Build u-boot::
> > > >
> > > >$ export CROSS_COMPILE=
> > > >$ make qcom_defconfig
> > > >$ make
> > > >
> > > > - gzip u-boot::
> > > >
> > > >gzip u-boot-nodtb.bin
> > > >
> > > > - Append dtb to gzipped u-boot::
> > > >
> > > > cat u-boot-nodtb.bin.gz
> > > > /arch/arm64/boot/dts/qcom/your-board.dtb >
> > > > u-boot-nodtb.bin.gz-dtb
> > >
> > > What is this?? Who or what uses a gzipped image with a single DT attached?
> >
> > The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
> > LK). It is the usual way Linux is booted on these platforms. U-boot is
> > being brought into this chain to leverage standardized EFI boot
> > processes.
>
> LK is Little kernel, I believe. That is an open source project, right?
> But I suppose it is BSD licensed so in fact the code is not available?
> Is ABL obsolete?

ABL: Android Boot Loader. I suppose it is somewhat derived from edk2
ABL EFI application. It's not obsolete but rather the one widely used
proprietary bootloader on recent SoCs (qcs404, sdm845 and all later
SoCs). Infact LK is somewhat 

[PATCH 30/30] mtd: spi-nor: Add support for locking on Spansion nor flashes

[Tejas Bhumkar]

From: Venkatesh Yadav Abbarapu 

Spansion nor flashes provide block protection support using
BP0, BP1, BP2 bits in status register.

The top/bottom select is instead done via a bit in the configuration
register, which is OTP, so once set to use bottom protect, one cannot
use top. On top of that, reading the configuration register uses a
different opcode (0x15) than the existing SPINOR_OP_RDCR (0x35).

Used bottom protect to test s25fl512s flash part lock/unlock
on zc1751+dc1 board.

Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 372 +
 include/linux/mtd/spi-nor.h|   1 +
 2 files changed, 373 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 3e2491cc3e..42483c 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -5465,6 +5465,370 @@ static int giga_flash_unlock(struct spi_nor *nor, 
loff_t ofs, uint64_t len)
return ret;
 }
 #endif /* CONFIG_SPI_FLASH_GIGADEVICE */
+
+#if defined(CONFIG_SPI_FLASH_SPANSION)
+/**
+ * spansion_read_cr() - read configuration register
+ * @nor: pointer to a 'struct spi_nor'.
+ *
+ * Spansion devices have top/bottom area protection bits selection into
+ * configuration reg. The bits in CR are OTP. So once it's written,
+ * it cannot be changed.
+ *
+ * Return: Value in configuration register or negative if error.
+ */
+static int spansion_read_cr(struct spi_nor *nor)
+{
+   int ret;
+   u8 val;
+
+   ret = nor->read_reg(nor, SPINOR_OP_RDCR, , 1);
+   if (ret < 0) {
+   dev_dbg(nor->dev, "error %d reading CR\n", ret);
+   return ret;
+   }
+
+   return val;
+}
+
+static void spansion_get_locked_range(struct spi_nor *nor, u8 sr, loff_t *ofs,
+ uint64_t *len)
+{
+   struct mtd_info *mtd = >mtd;
+   int pow, cr;
+   int shift = 0;
+   u8 mask =  SR_BP0 | SR_BP1 | SR_BP2;
+
+   shift = ffs(mask) - 1;
+
+   cr = spansion_read_cr(nor);
+   if (!(sr & mask)) {
+   /* No protection */
+   *ofs = 0;
+   *len = 0;
+   } else {
+   pow = ((sr & mask) ^ mask) >> shift;
+   *len = mtd->size >> pow;
+   /* SPANSION device's have top/bottom select bit in 
configuration reg */
+   if (nor->flags & SNOR_F_HAS_SR_TB && cr & CR_TB_SPAN)
+   *ofs = 0;
+   else
+   *ofs = mtd->size - *len;
+   }
+}
+
+/**
+ * spansion_check_lock_status_sr() - check the status register and return
+ * the region is locked or unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ * @locked: locked:1 unlocked:0 value
+ *
+ * Return: 1 if the entire region is locked (if @locked is true) or unlocked 
(if
+ * @locked is false); 0 otherwise.
+ */
+static int spansion_check_lock_status_sr(struct spi_nor *nor, loff_t ofs, u64 
len,
+u8 sr, bool locked)
+{
+   loff_t lock_offs;
+   u64 lock_len;
+
+   if (!len)
+   return 1;
+
+   spansion_get_locked_range(nor, sr, _offs, _len);
+   if (locked)
+   /* Requested range is a sub-range of locked range */
+   return (ofs + len <= lock_offs + lock_len) && (ofs >= 
lock_offs);
+
+   /* Requested range does not overlap with locked range */
+   return (ofs >= lock_offs + lock_len) || (ofs + len <= lock_offs);
+}
+
+/**
+ * spansion_is_locked_sr() - check if the memory region is locked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ *
+ * Check if memory region is locked.
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int spansion_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
+u8 sr)
+{
+   return spansion_check_lock_status_sr(nor, ofs, len, sr, true);
+}
+
+/**
+ * spansion_is_unlocked_sr() - check if the memory region is unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ *
+ * Check if memory region is unlocked.
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int spansion_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, uint64_t 
len,
+  u8 sr)
+{
+   return spansion_check_lock_status_sr(nor, ofs, len, sr, false);
+}
+
+/**
+ * spansion_is_unlocked() - check if the memory region is unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ *
+ * check if memory region is unlocked
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int spansion_is_unlocked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+{
+  

[PATCH 28/30] mtd: spi-nor: Add support for locking on ISSI nor flashes

[Tejas Bhumkar]

From: Venkatesh Yadav Abbarapu 

ISSI chips implements locking in (power-of-two multiple of) 64K
blocks, not as a fraction of the chip's size. Bit 5 in the status
register is not a top/bottom select bit, but instead a fourth value
bit, allowing locking between 2^0 and 2^14 64K blocks (so up to 1GiB),
either from top or bottom.

The top/bottom select is instead done via a bit in the function
register, which is OTP, so once set to use bottom protect, one cannot
use top. On top of that, reading the function register uses a
opcode SPINOR_OP_RDFR (0x48) and writing to the function register uses the
opcode SPINOR_OP_WRFR(0x42).

Here's an attempt at implementing a locking feature for ISSI flash memory
devices. This implementation has been rigorously tested and proven to work
on the chip used in our boards. Additionally, after examining data sheets
for various other ISSI chips, it appears that they follow a similar
behavior.

Used "bottom protect" to test the lock and unlock functionality on the
Versal Tenzing board. Please note that the Block Protection table is
specific to the IS25LP01G, which has a size of 128MB, a sector size
of 64KB, and comprises 2048 sectors.

Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/sf_internal.h  |   6 +
 drivers/mtd/spi/spi-nor-core.c | 340 +
 include/linux/mtd/spi-nor.h|   7 +
 3 files changed, 353 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 2cbdea60b0..aaa8520838 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -71,6 +71,12 @@ struct flash_info {
 #define SPI_NOR_OCTAL_DTR_READ BIT(17) /* Flash supports Octal DTR Read */
 #define SPI_NOR_OCTAL_DTR_PP   BIT(18) /* Flash supports Octal DTR page 
program */
 #define SPI_NOR_MULTI_DIE  BIT(19) /* Flash has multi dies & need split 
reads*/
+#define SPI_NOR_HAS_BP3BIT(20) /* Flash SR has block protect 
bits
+* for lock/unlock purpose, few support
+* BP0-BP2 while few support BP0-BP3.
+* This flag identifies devices that
+* support BP3 bit.
+*/
 };
 
 extern const struct flash_info spi_nor_ids[];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 08f6fb66be..3bf1e5471b 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -4832,6 +4832,338 @@ static int mx_is_unlocked(struct spi_nor *nor, loff_t 
ofs, uint64_t len)
return mx_check_lock_status(nor, ofs, len, sr, cr, false);
 }
 #endif /* CONFIG_SPI_FLASH_MACRONIX */
+
+#if defined(CONFIG_SPI_FLASH_ISSI)
+/**
+ * spi_nor_read_fr() - read function register
+ * @nor: pointer to a 'struct spi_nor'.
+ *
+ * ISSI devices have top/bottom area protection bits selection into function
+ * reg. The bits in FR are OTP. So once it's written, it cannot be changed.
+ *
+ * Return: Value in function register or negative if error.
+ */
+static int spi_nor_read_fr(struct spi_nor *nor)
+{
+   int ret;
+   u8 val;
+
+   ret = nor->read_reg(nor, SPINOR_OP_RDFR, , 1);
+   if (ret < 0) {
+   dev_dbg(nor->dev, "error %d reading FR\n", ret);
+   return ret;
+   }
+
+   return val;
+}
+
+static void issi_get_locked_range(struct spi_nor *nor, u8 sr, loff_t *ofs,
+ uint64_t *len)
+{
+   struct mtd_info *mtd = >mtd;
+   u8 mask = 0, fr = 0;
+   int pow, shift;
+   u32 sector_size;
+
+   mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3_ISSI;
+   shift = ffs(mask) - 1;
+   sector_size = nor->sector_size;
+
+   if (nor->flags & SNOR_F_HAS_PARALLEL)
+   sector_size >>= 1;
+
+   if (!(sr & mask)) {
+   /* No protection */
+   *ofs = 0;
+   *len = 0;
+   } else {
+   pow = ((sr & mask) >> shift) - 1;
+   *len = sector_size << pow;
+   if (*len > mtd->size)
+   *len = mtd->size;
+   /* ISSI device's have top/bottom select bit in function reg */
+   fr = spi_nor_read_fr(nor);
+   if (fr & FR_TB)
+   *ofs = 0;
+   else
+   *ofs = mtd->size - *len;
+   }
+}
+
+/**
+ * issi_check_lock_status_sr() - check the status register and return
+ * the region is locked or unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ * @locked: locked:1 unlocked:0 value
+ *
+ * Return: 1 if the entire region is locked (if @locked is true) or unlocked 
(if
+ * @locked is false); 0 otherwise.
+ */
+static int issi_check_lock_status_sr(struct spi_nor *nor, loff_t ofs, u64 len,
+

[PATCH 25/30] arm64: versal: Enable octal DTR mode

[Tejas Bhumkar]

The Cadence driver must switch between SDR and DTR modes based
on commands from the SPI-NOR framework and the configuration
set by SPI_FLASH_DTR_ENABLE. If SPI_FLASH_DTR_ENABLE is enabled,
the driver should transition to DTR mode; if it is not defined,
the driver should avoid switching to DTR mode, signaling that
the controller does not support DTR.

Signed-off-by: Tejas Bhumkar 
---
 configs/xilinx_versal_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_virt_defconfig 
b/configs/xilinx_versal_virt_defconfig
index ee247b905f..69835fce55 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -98,6 +98,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_SOFT_RESET=y
 CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
 CONFIG_SPI_FLASH_MT35XU=y
+CONFIG_SPI_FLASH_DTR_ENABLE=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
-- 
2.27.0

[PATCH 29/30] mtd: spi-nor: Add support for locking on GIGADEVICE nor flashes

[Tejas Bhumkar]

From: Venkatesh Yadav Abbarapu 

GIGADEVICE nor flashes provide block protection support using
BP0, BP1, BP2, BP3 & TB bits in status register.

BP(Block Protection) bits defines memory to be software
protected against PROGRAM or ERASE operations. When one or more
block protect bits are set to 1, a designated memory area is
protected from PROGRAM and ERASE operations. TB(Top/Bottom) bit
determines whether the protected memory area defined by the block
protect bits starts from the top or bottom of the memory array.

Used bottom/top protect to test lock/unlock on zc1751+dc1 board.

Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 309 +
 include/linux/mtd/spi-nor.h|   2 +
 2 files changed, 311 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 3bf1e5471b..3e2491cc3e 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -5164,6 +5164,307 @@ static int issi_flash_unlock(struct spi_nor *nor, 
loff_t ofs, uint64_t len)
return ret;
 }
 #endif /* CONFIG_SPI_FLASH_ISSI */
+
+#if defined(CONFIG_SPI_FLASH_GIGADEVICE)
+static void giga_get_locked_range(struct spi_nor *nor, u8 sr, loff_t *ofs,
+ uint64_t *len)
+{
+   struct mtd_info *mtd = >mtd;
+   int shift = 0;
+   int pow;
+   u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3_GIGA;
+   u32 sector_size;
+
+   sector_size = nor->sector_size;
+   if (nor->flags & SNOR_F_HAS_PARALLEL)
+   sector_size >>= 1;
+
+   shift = ffs(mask) - 1;
+
+   if (!(sr & mask)) {
+   /* No protection */
+   *ofs = 0;
+   *len = 0;
+   } else {
+   pow = ((sr & mask) >> shift) - 1;
+   *len = sector_size << pow;
+   if (*len > mtd->size)
+   *len = mtd->size;
+   /* GIGA device's have top/bottom select bit in status reg */
+   if (nor->flags & SNOR_F_HAS_SR_TB && sr & SR_TB_GIGA)
+   *ofs = 0;
+   else
+   *ofs = mtd->size - *len;
+   }
+}
+
+/**
+ * giga_check_lock_status_sr() - check the status register and return
+ * the region is locked or unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ * @locked: locked:1 unlocked:0 value
+ *
+ * Return: 1 if the entire region is locked (if @locked is true) or unlocked 
(if
+ * @locked is false); 0 otherwise.
+ */
+static int giga_check_lock_status_sr(struct spi_nor *nor, loff_t ofs, u64 len,
+u8 sr, bool locked)
+{
+   loff_t lock_offs;
+   u64 lock_len;
+
+   if (!len)
+   return 1;
+
+   giga_get_locked_range(nor, sr, _offs, _len);
+   if (locked)
+   /* Requested range is a sub-range of locked range */
+   return (ofs + len <= lock_offs + lock_len) && (ofs >= 
lock_offs);
+
+   /* Requested range does not overlap with locked range */
+   return (ofs >= lock_offs + lock_len) || (ofs + len <= lock_offs);
+}
+
+/**
+ * giga_is_locked_sr() - check if the memory region is locked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ *
+ * Check if memory region is locked.
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int giga_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
+u8 sr)
+{
+   return giga_check_lock_status_sr(nor, ofs, len, sr, true);
+}
+
+/**
+ * giga_is_unlocked_sr() - check if the memory region is unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ * @sr:  status register
+ *
+ * Check if memory region is unlocked.
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int giga_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
+  u8 sr)
+{
+   return giga_check_lock_status_sr(nor, ofs, len, sr, false);
+}
+
+/**
+ * giga_is_unlocked() - check if the memory region is unlocked
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset of the flash
+ * @len: length to be locked
+ *
+ * Check if memory region is unlocked
+ *
+ * Return: false if region is locked 0 otherwise.
+ */
+static int giga_is_unlocked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+{
+   int sr;
+
+   sr = read_sr(nor);
+   if (sr < 0)
+   return sr;
+
+   return giga_check_lock_status_sr(nor, ofs, len, sr, false);
+}
+
+/**
+ * giga_nor_select_zone() - Select top area or bottom area to lock/unlock
+ * @nor: pointer to a 'struct spi_nor'.
+ * @ofs: offset from which to lock memory.
+ * @len: number of bytes to unlock.
+ * @sr: status register
+ * @tb: pointer to top/bottom bool 

[PATCH 27/30] mtd: spi-nor: Add support for locking on Macronix nor flashes

[Tejas Bhumkar]

From: Venkatesh Yadav Abbarapu 

Macronix chips implements locking in (power-of-two multiple of) 64K
blocks, not as a fraction of the chip's size. Bit 5 in the status
register is not a top/bottom select bit, but instead a fourth value
bit, allowing locking between 2^0 and 2^14 64K blocks (so up to 1GiB),
either from top or bottom.

The top/bottom select is instead done via a bit in the configuration
register, which is OTP, so once set to use bottom protect, one cannot
use top. On top of that, reading the configuration register uses a
different opcode (0x15) than the existing SPINOR_OP_RDCR (0x35).

Here's an attempt to implement locking support for Macronix flash
memory devices. This implementation has been tested and confirmed to
work on the specific chip used on our boards. Additionally, based
on the information from data sheets of various other Macronix chips,
suggest they behave in the same way.

Used bottom protect to test the locking and unlocking functionality
on the zc1751+dc1 board.

Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 259 +
 include/linux/mtd/spi-nor.h|   3 +
 2 files changed, 262 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index c40899a281..08f6fb66be 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -4581,6 +4581,257 @@ static int micron_is_unlocked(struct spi_nor *nor, 
loff_t ofs, uint64_t len)
return micron_is_unlocked_sr(nor, ofs, len, status);
 }
 #endif /* CONFIG_SPI_FLASH_STMICRO */
+
+#if defined(CONFIG_SPI_FLASH_MACRONIX)
+/**
+ * mx_write_sr_cr() - write status and configuration register
+ * @nor: pointer to a 'struct spi_nor'
+ * @sr_cr: pointer status and configuration register
+ *
+ * Write status Register and configuration register with 2 bytes
+ * The first byte will be written to the status register, while the
+ * second byte will be written to the configuration register.
+ *
+ * Return: 0 on success, -errno if error occurred.
+ */
+static int mx_write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
+{
+   int ret;
+
+   write_enable(nor);
+
+   ret = nor->write_reg(nor, SPINOR_OP_WRSR, sr_cr, 2);
+   if (ret < 0) {
+   dev_dbg(nor->dev,
+   "error while writing configuration register\n");
+   return -EINVAL;
+   }
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret) {
+   dev_dbg(nor->dev,
+   "timeout while writing configuration register\n");
+   return ret;
+   }
+
+   ret = write_disable(nor);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int mx_read_cr(struct spi_nor *nor)
+{
+   int ret;
+   u8 val;
+
+   ret = nor->read_reg(nor, SPINOR_OP_RDCR_MX, , 1);
+   if (ret < 0) {
+   dev_dbg(nor->dev, "error %d reading CR\n", ret);
+   return ret;
+   }
+
+   return val;
+}
+
+/**
+ * mx_get_locked_range() - get the locked range
+ * @nor: pointer to a 'struct spi_nor'
+ * @sr:  status register
+ * @cr:  configuration register
+ * @ofs: flash offset
+ * @len: length to be locked
+ *
+ * Macronix flashes do not work by locking some 1/2^k fraction of the
+ * flash - instead, the BP{0,1,2,3} bits define a number of protected
+ * 64K blocks.
+ */
+static void mx_get_locked_range(struct spi_nor *nor, u8 sr, u8 cr,
+   loff_t *ofs, uint64_t *len)
+{
+   struct mtd_info *mtd = >mtd;
+   int pow, shift;
+   u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3_MX;
+
+   shift = ffs(mask) - 1;
+
+   pow = ((sr & mask) >> shift) - 1;
+   if (pow < 0) {
+   /* No protection */
+   *ofs = 0;
+   *len = 0;
+   } else {
+   *len = (uint64_t)SZ_64K << pow;
+   if (*len > mtd->size)
+   *len = mtd->size;
+   if (cr & CR_TB_MX)
+   *ofs = 0;
+   else
+   *ofs = mtd->size - *len;
+   }
+}
+
+/**
+ * mx_check_lock_status() - check the locked status
+ * @nor: pointer to a 'struct spi_nor'
+ * @ofs: flash offset
+ * @len: length to be locked
+ * @sr:  status register
+ * @cr:  configuration register
+ * @locked: locked:1 unlocked:0 value
+ *
+ * Return: 1 if the entire region is locked (if @locked is true) or unlocked 
(if
+ * @locked is false); 0 otherwise.
+ */
+static int mx_check_lock_status(struct spi_nor *nor, loff_t ofs, u64 len,
+   u8 sr, u8 cr, bool locked)
+{
+   loff_t lock_offs;
+   u64 lock_len;
+
+   if (!len)
+   return 1;
+
+   mx_get_locked_range(nor, sr, cr, _offs, _len);
+
+   if (locked)
+   /* Requested range is a sub-range of locked range */
+   return (ofs + len <= lock_offs + lock_len) && (ofs >= 
lock_offs);
+
+

[PATCH 23/30] spi: cadence_qspi: Write aligned byte length to ahbbase

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Incase of non-aligned length of flash data, ahbbase address is written
directly with byte count. This is causing AHB bus error's sometimes and
resulting in kernel crash while booting linux. To avoid this write 4 byte
aligned byte count to ahbbase address.

Also use a temporary variable with 0x data and overwrite this
temp with unaligned bytes data before writing to ahbbase.

The value 0x is chosen as this is flash memory, worst case we
will write 0xff to any location which doesn't effect any bits.

Signed-off-by: Ashok Reddy Soma 
State: pending
---
 drivers/spi/cadence_qspi_apb.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 43dc4c6e70..1d0e6c2180 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -934,10 +934,12 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
writesl(priv->ahbbase, bb_txbuf, write_bytes >> 2);
-   if (write_bytes % 4)
-   writesb(priv->ahbbase,
-   bb_txbuf + rounddown(write_bytes, 4),
-   write_bytes % 4);
+   if (write_bytes % 4) {
+   unsigned int temp = 0x;
+
+   memcpy(, bb_txbuf + rounddown(write_bytes, 4), 
write_bytes % 4);
+   writel(temp, priv->ahbbase);
+   }
 
/* Wait up to Indirect Operation Complete bit to set */
ret = readl_poll_timeout(priv->regbase + CQSPI_REG_IRQSTATUS, 
cr,
-- 
2.27.0

[PATCH 26/30] mtd: spi-nor: Add block protection support for micron flashes

[Tejas Bhumkar]

From: T Karthik Reddy 

Micron nor flashes provide block protection support using
BP0, BP1, BP2, BP3 & TB bits in status register. This patch
supports for micron nor flashes with manufacturer id 0x20
and 0x2c.

Where BP(Block Protection) bits defines memory to be software
protected against PROGRAM or ERASE operations. When one or more
block protect bits are set to 1, a designated memory area is
protected from PROGRAM and ERASE operations. TB(Top/Bottom) bit
determines whether the protected memory area defined by the block
protect bits starts from the top or bottom of the memory array.

Block Protection table for N25Q00AA with size 128MB, sector size 64KB
and with 2048 sectors.

Top protection:
--
TB  BP3 BP2 BP1 BP0 Protected Area  Un-Protected 
Area
0   0   0   0   0   NoneAll sectors
0   0   0   0   1   Sector 2047 Sectors (0 to 
2046)
0   0   0   1   0   Sectors (2046 to 2047)  Sectors (0 to 
2045)
0   0   0   1   1   Sectors (2044 to 2047)  Sectors (0 to 
2043)
0   0   1   0   0   Sectors (2040 to 2047)  Sectors (0 to 
2039)
0   0   1   0   1   Sectors (2032 to 2047)  Sectors (0 to 
2031)
0   0   1   1   0   Sectors (2016 to 2047)  Sectors (0 to 
2015)
0   0   1   1   1   Sectors (1984 to 2047)  Sectors (0 to 
1983)
0   1   0   0   0   Sectors (1920 to 2047)  Sectors (0 to 
1919)
0   1   0   0   1   Sectors (1792 to 2047)  Sectors (0 to 
1791)
0   1   0   1   0   Sectors (1936 to 2047)  Sectors (0 to 
1535)
0   1   0   1   1   Sectors (1024 to 2047)  None

Bottom protection:
-
TB  BP3 BP2 BP1 BP0 Protected Area  Un-protected 
Area
1   0   0   0   0   NoneAll sectors
1   0   0   0   1   sector 0Sectors (1 to 
2047)
1   0   0   1   0   Sectors (0 to 1)Sectors (2 to 
2047)
1   0   0   1   1   Sectors (0 to 3)Sectors (4 to 
2047)
1   0   1   0   0   Sectors (0 to 7)Sectors (8 to 
2047)
1   0   1   0   1   Sectors (0 to 15)   Sectors (16 to 
2047)
1   0   1   1   0   Sectors (0 to 31)   Sectors (32 to 
2047)
1   0   1   1   1   Sectors (0 to 63)   Sectors (64 to 
2047)
1   1   0   0   0   Sectors (0 to 127)  Sectors (128 to 
2047)
1   1   0   0   1   Sectors (0 to 255)  Sectors (256 to 
2047)
1   1   0   1   0   Sectors (0 to 511)  Sectors (512 to 
2047)
1   1   0   1   1   Sectors (0 to 1023) Sectors (1024 
to 2047)

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Ashok Reddy Soma 
Signed-off-by: T Karthik Reddy 
Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 255 +
 include/linux/mtd/spi-nor.h|   7 +
 2 files changed, 262 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index ccda722df5..c40899a281 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -4336,6 +4336,253 @@ static int spi_nor_init(struct spi_nor *nor)
return 0;
 }
 
+#if defined(CONFIG_SPI_FLASH_LOCK)
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+static inline uint16_t min_lockable_sectors(struct spi_nor *nor,
+   uint16_t n_sectors)
+{
+   /* lock granularity */
+   return 1;
+}
+
+static inline uint32_t get_protected_area_start(struct spi_nor *nor,
+   u8 lock_bits,
+   bool is_bottom)
+{
+   u16 n_sectors;
+   u32 sector_size, flash_size;
+   int ret;
+
+   sector_size = nor->sector_size;
+
+   if (nor->flags & SNOR_F_HAS_PARALLEL) {
+   n_sectors = (nor->size >> 0x01) / sector_size;
+   flash_size = nor->size >> 0x01;
+   } else {
+   n_sectors = nor->size / sector_size;
+   flash_size = nor->size;
+   }
+
+   if (!is_bottom)
+   ret = flash_size - ((1 << (lock_bits - 1)) * sector_size *
+   min_lockable_sectors(nor, n_sectors));
+   else
+   ret = (1 << (lock_bits - 1)) * sector_size *
+  min_lockable_sectors(nor, n_sectors);
+
+   return ret;
+}
+
+static uint8_t min_protected_area_including_offset(struct spi_nor *nor,
+  u32 offset,
+  bool is_bottom)
+{
+   u8 lock_bits, lockbits_limit;
+
+ 

[PATCH 22/30] spi: cadence_qspi: Add spi mem dtr support ops

[Tejas Bhumkar]

From: T Karthik Reddy 

In DDR mode, current default spi_mem_dtr_supports_op() function does
not allow mixed DTR operation functionality. So implement cadence
specific cadence_spi_mem_dtr_supports_op() function to verifying only
the command buswidth and command opcode bytes which satisfies the DTR
protocol.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 710c4a532d..282028c845 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -718,6 +718,21 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
return err;
 }
 
+static bool cadence_spi_mem_dtr_supports_op(struct spi_slave *slave,
+   const struct spi_mem_op *op)
+{
+   /*
+* In DTR mode, except op->cmd all other parameters like address,
+* dummy and data could be 0.
+* So lets only check if the cmd buswidth and number of opcode bytes
+* are true for DTR to support.
+*/
+   if (op->cmd.buswidth == 8 && op->cmd.nbytes % 2)
+   return false;
+
+   return true;
+}
+
 static bool cadence_spi_mem_supports_op(struct spi_slave *slave,
const struct spi_mem_op *op)
 {
@@ -740,7 +755,7 @@ static bool cadence_spi_mem_supports_op(struct spi_slave 
*slave,
return false;
 
if (all_true)
-   return spi_mem_dtr_supports_op(slave, op);
+   return cadence_spi_mem_dtr_supports_op(slave, op);
else
return spi_mem_default_supports_op(slave, op);
 }
-- 
2.27.0

[PATCH 24/30] arm64: versal: Enable soft reset support for xspi flashes

[Tejas Bhumkar]

Activate the xSPI Software Reset support, which will be
utilized to transition from octal DTR mode to legacy
mode during shutdown and boot (if enabled).

Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 configs/xilinx_versal_virt_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/xilinx_versal_virt_defconfig 
b/configs/xilinx_versal_virt_defconfig
index ec7caacca0..ee247b905f 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -95,6 +95,8 @@ CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_ZYNQ_SDHCI_MIN_FREQ=10
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
 CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
-- 
2.27.0

[PATCH 21/30] spi: cadence_qspi: Enable ECO bit for higher frequencies

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Enable ECO bit for Versal for frequencies above 120Mhz
for octal spi to work properly.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi.h | 1 +
 drivers/spi/cadence_qspi_apb.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 73ef44fc1c..4906b9ef96 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -55,6 +55,7 @@
 #define CQSPI_READ_ID_LEN  3
 #define CQSPI_READID_LOOP_MAX  10
 #define TERA_MACRO 1l
+#define TAP_GRAN_SEL_MIN_FREQ  12000
 
 #define OSPI_CTRL_RST  0xF1260304
 
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 052d7a1766..43dc4c6e70 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -382,6 +382,10 @@ void cadence_qspi_apb_controller_init(struct 
cadence_spi_priv *priv)
 
writel(reg, priv->regbase + CQSPI_REG_CONFIG);
 
+   if (IS_ENABLED(CONFIG_ARCH_VERSAL) &&
+   priv->ref_clk_hz >= TAP_GRAN_SEL_MIN_FREQ)
+   writel(1, priv->regbase + CQSPI_REG_ECO);
+
cadence_qspi_apb_controller_enable(priv->regbase);
 }
 
-- 
2.27.0

[PATCH 20/30] spi: cadence_qspi: Initialize read and write watermark registers

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Read and Write watermark registers are not initialized. Set read
watermark to half of the FIFO and write watermark to 1/8 of the
FIFO size.

Read watermark indicates if SRAM fill level is above this watermark,
interrupt will be generated and read or DMA can be performed.

Write watermark indicates the maximum fill level of SRAM when write is
performed to device.

These values of 1/2 for read and 1/8 for write are chosen similar to
Linux driver.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi_apb.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 5fc5279061..052d7a1766 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -362,6 +362,14 @@ void cadence_qspi_apb_controller_init(struct 
cadence_spi_priv *priv)
/* Indirect mode configurations */
writel(priv->fifo_depth / 2, priv->regbase + CQSPI_REG_SRAMPARTITION);
 
+   /* Program read watermark -- 1/2 of the FIFO. */
+   writel(priv->fifo_depth * priv->fifo_width / 2,
+  priv->regbase + CQSPI_REG_INDIRECTRDWATERMARK);
+
+   /* Program write watermark -- 1/8 of the FIFO. */
+   writel(priv->fifo_depth * priv->fifo_width / 8,
+  priv->regbase + CQSPI_REG_INDIRECTWRWATERMARK);
+
/* Disable all interrupts */
writel(0, priv->regbase + CQSPI_REG_IRQMASK);
 
-- 
2.27.0

[PATCH 19/30] spi: cadence_qspi: Clean up registers in init

[Tejas Bhumkar]

From: Ashok Reddy Soma 

This patch cleans up the cadence qspi registers in the init.
The register contents may be invalid if this controller is
used in previous boot and comes to uboot after a softreset
(no power on reset). This may cause issues in uboot.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi_apb.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 0bb46f6ac2..5fc5279061 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -346,12 +346,34 @@ void cadence_qspi_apb_controller_init(struct 
cadence_spi_priv *priv)
/* Configure the remap address register, no remap */
writel(0, priv->regbase + CQSPI_REG_REMAP);
 
+   /* Clear instruction read config register */
+   writel(0, priv->regbase + CQSPI_REG_RD_INSTR);
+
+   /* Reset the Delay lines */
+   writel(CQSPI_REG_PHY_CONFIG_RESET_FLD_MASK,
+  priv->regbase + CQSPI_REG_PHY_CONFIG);
+
+   reg = readl(priv->regbase + CQSPI_REG_RD_DATA_CAPTURE);
+   reg &= ~CQSPI_REG_READCAPTURE_DQS_ENABLE;
+   reg &= ~(CQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK
+<< CQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB);
+   writel(reg, priv->regbase + CQSPI_REG_RD_DATA_CAPTURE);
+
/* Indirect mode configurations */
writel(priv->fifo_depth / 2, priv->regbase + CQSPI_REG_SRAMPARTITION);
 
/* Disable all interrupts */
writel(0, priv->regbase + CQSPI_REG_IRQMASK);
 
+   reg = readl(priv->regbase + CQSPI_REG_CONFIG);
+   reg &= ~CQSPI_REG_CONFIG_DTR_PROT_EN_MASK;
+   reg &= ~CQSPI_REG_CONFIG_PHY_ENABLE_MASK;
+   reg &= ~CQSPI_REG_CONFIG_DIRECT;
+   reg &= ~(CQSPI_REG_CONFIG_CHIPSELECT_MASK
+   << CQSPI_REG_CONFIG_CHIPSELECT_LSB);
+
+   writel(reg, priv->regbase + CQSPI_REG_CONFIG);
+
cadence_qspi_apb_controller_enable(priv->regbase);
 }
 
-- 
2.27.0

[PATCH 16/30] spi: cadence_ospi_versal: ospi ddr changes in cadence ospi versal driver

[Tejas Bhumkar]

From: T Karthik Reddy 

Set cmd, address & data buswidth to octal. Handle dummy clock
cycles incase of reads & writes. Convert odd bytes to even
bytes lengths in ddr mode, as we cannot rx/tx odd data in
ddr mode.

Disable the DMA once the transfer is done to avoid disabling
it at other places.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_ospi_versal.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/cadence_ospi_versal.c 
b/drivers/spi/cadence_ospi_versal.c
index 243de6efaf..9db190 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -21,12 +21,13 @@
 
 #define CMD_4BYTE_READ  0x13
 #define CMD_4BYTE_FAST_READ  0x0C
+#define CMD_4BYTE_OCTAL_READ 0x7c
 
 int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
  const struct spi_mem_op *op)
 {
u32 reg, ret, rx_rem, n_rx, bytes_to_dma, data;
-   u8 opcode, addr_bytes, *rxbuf, dummy_cycles;
+   u8 opcode, addr_bytes, *rxbuf, dummy_cycles, unaligned_byte;
 
n_rx = op->data.nbytes;
rxbuf = op->data.buf.in;
@@ -70,13 +71,14 @@ int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
writel(CQSPI_REG_INDIRECTRD_DONE, priv->regbase +
   CQSPI_REG_INDIRECTRD);
rxbuf += bytes_to_dma;
-   }
 
-   if (rx_rem) {
+   /* Disable DMA on completion */
reg = readl(priv->regbase + CQSPI_REG_CONFIG);
reg &= ~CQSPI_REG_CONFIG_ENBL_DMA;
writel(reg, priv->regbase + CQSPI_REG_CONFIG);
+   }
 
+   if (rx_rem) {
reg = readl(priv->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
reg += bytes_to_dma;
writel(reg, priv->regbase + CQSPI_REG_CMDADDRESS);
@@ -84,10 +86,10 @@ int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
addr_bytes = readl(priv->regbase + CQSPI_REG_SIZE) &
   CQSPI_REG_SIZE_ADDRESS_MASK;
 
-   opcode = CMD_4BYTE_FAST_READ;
-   dummy_cycles = 8;
-   writel((dummy_cycles << CQSPI_REG_RD_INSTR_DUMMY_LSB) | opcode,
-  priv->regbase + CQSPI_REG_RD_INSTR);
+   opcode = (u8)readl(priv->regbase + CQSPI_REG_RD_INSTR);
+   if (opcode == CMD_4BYTE_OCTAL_READ &&
+   priv->edge_mode != CQSPI_EDGE_MODE_DDR)
+   opcode = CMD_4BYTE_FAST_READ;
 
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -99,7 +101,12 @@ int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
CQSPI_REG_RD_INSTR_DUMMY_MASK;
reg |= (dummy_cycles & CQSPI_REG_CMDCTRL_DUMMY_MASK) <<
CQSPI_REG_CMDCTRL_DUMMY_LSB;
-   reg |= (((rx_rem - 1) & CQSPI_REG_CMDCTRL_RD_BYTES_MASK) <<
+   if (priv->edge_mode == CQSPI_EDGE_MODE_DDR && (rx_rem % 2) != 0)
+   unaligned_byte = 1;
+   else
+   unaligned_byte = 0;
+   reg |= (((rx_rem - 1 + unaligned_byte) &
+   CQSPI_REG_CMDCTRL_RD_BYTES_MASK) <<
CQSPI_REG_CMDCTRL_RD_BYTES_LSB);
ret = cadence_qspi_apb_exec_flash_cmd(priv->regbase, reg);
if (ret)
-- 
2.27.0

[PATCH 17/30] spi: cadence_qspi: Fix versal ospi indirect write timed out issue

[Tejas Bhumkar]

To reduce the CPU load in waiting for the OSPI internal SRAM to
clear in indirect mode, it's better to use the
CQSPI_REG_IRQSTATUS register to check for indirect operation to complete.
Enabled interrupt for Indirect Complete and Transfer Watermark
Breach interrupt status register bits and using readl_poll_timeout
function to poll for Indirect Operation Complete bit gets set.

Here not enabling IRQ coming to GIC, only IRQ from IP itself is able
to poll bits.

It is observed that the Indirect Operation Complete bit is getting
set at an average time of 0.172 usec.

Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi.h | 11 +++
 drivers/spi/cadence_qspi_apb.c | 24 +++-
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 505f59bed9..73ef44fc1c 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -252,6 +252,17 @@
(((readl((reg_base) + CQSPI_REG_SDRAMLEVEL)) >> \
CQSPI_REG_SDRAMLEVEL_WR_LSB) & CQSPI_REG_SDRAMLEVEL_WR_MASK)
 
+/* Interrupt status bits */
+#define CQSPI_REG_IRQ_UNDERFLOW BIT(1)
+#define CQSPI_REG_IRQ_IND_COMP  BIT(2)
+#define CQSPI_REG_IRQ_WATERMARK BIT(6)
+
+#define CQSPI_IRQ_MASK_WR  (CQSPI_REG_IRQ_IND_COMP
| \
+   CQSPI_REG_IRQ_WATERMARK
| \
+   CQSPI_REG_IRQ_UNDERFLOW)
+
+#define CQSPI_IRQ_STATUS_MASK  GENMASK(16, 0)
+
 struct cadence_spi_plat {
unsigned intmax_hz;
void*regbase;
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index d1a5a4c679..1b649abf21 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -855,7 +856,7 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
const u8 *bb_txbuf = txbuf;
void *bounce_buf = NULL;
unsigned int write_bytes;
-   int ret;
+   int ret, cr;
 
if (priv->edge_mode == CQSPI_EDGE_MODE_DDR && (n_tx % 2) != 0)
n_tx++;
@@ -873,9 +874,15 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
bb_txbuf = bounce_buf;
}
 
-   /* Configure the indirect read transfer bytes */
+   /* Configure the indirect write transfer bytes */
writel(n_tx, priv->regbase + CQSPI_REG_INDIRECTWRBYTES);
 
+   /* Clear all interrupts */
+   writel(CQSPI_IRQ_STATUS_MASK, priv->regbase + CQSPI_REG_IRQSTATUS);
+
+   /* Enable interrupt for corresponding interrupt status register bit's */
+   writel(CQSPI_IRQ_MASK_WR, priv->regbase + CQSPI_REG_IRQMASK);
+
/* Start the indirect write transfer */
writel(CQSPI_REG_INDIRECTWR_START,
   priv->regbase + CQSPI_REG_INDIRECTWR);
@@ -894,9 +901,10 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
bb_txbuf + rounddown(write_bytes, 4),
write_bytes % 4);
 
-   ret = wait_for_bit_le32(priv->regbase + CQSPI_REG_SDRAMLEVEL,
-   CQSPI_REG_SDRAMLEVEL_WR_MASK <<
-   CQSPI_REG_SDRAMLEVEL_WR_LSB, 0, 10, 0);
+   /* Wait up to Indirect Operation Complete bit to set */
+   ret = readl_poll_timeout(priv->regbase + CQSPI_REG_IRQSTATUS, 
cr,
+cr & CQSPI_REG_IRQ_IND_COMP, 10);
+
if (ret) {
printf("Indirect write timed out (%i)\n", ret);
goto failwr;
@@ -914,6 +922,9 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
goto failwr;
}
 
+   /* Disable interrupt. */
+   writel(0, priv->regbase + CQSPI_REG_IRQMASK);
+
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTWR_DONE,
   priv->regbase + CQSPI_REG_INDIRECTWR);
@@ -931,6 +942,9 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_priv *priv,
return 0;
 
 failwr:
+   /* Disable interrupt. */
+   writel(0, priv->regbase + CQSPI_REG_IRQMASK);
+
/* Cancel the indirect write */
writel(CQSPI_REG_INDIRECTWR_CANCEL,
   priv->regbase + CQSPI_REG_INDIRECTWR);
-- 
2.27.0

[PATCH 18/30] spi: cadence_qspi: Set tshsl_ns to at least one sclk_ns

[Tejas Bhumkar]

From: Ashok Reddy Soma 

tshsl_ns is the clock delay for chip select deassert. This is the delay in
master reference clocks for the length that the master mode chip select
outputs are de-asserted between transactions.

The minimum delay is always SCLK period to ensure the chip select is never
re-asserted within one SCLK period.

That is why tshsl_ns delay should be at least one sclk_ns value. If it is
less than sclk_ns, set it equal to sclk_ns.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_qspi_apb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 1b649abf21..0bb46f6ac2 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -306,6 +306,10 @@ void cadence_qspi_apb_delay(void *reg_base,
tshsl_ns -= sclk_ns + ref_clk_ns;
if (tchsh_ns >= sclk_ns + 3 * ref_clk_ns)
tchsh_ns -= sclk_ns + 3 * ref_clk_ns;
+
+   if (tshsl_ns < sclk_ns)
+   tshsl_ns = sclk_ns;
+
tshsl = DIV_ROUND_UP(tshsl_ns, ref_clk_ns);
tchsh = DIV_ROUND_UP(tchsh_ns, ref_clk_ns);
tslch = DIV_ROUND_UP(tslch_ns, ref_clk_ns);
-- 
2.27.0

[PATCH 15/30] spi: cadence-qspi: Switch SDR/DTR using SPI_FLASH_DTR_ENABLE config

[Tejas Bhumkar]

From: T Karthik Reddy 

Cadence driver need to switch from SDR to DTR and vice versa based on
the commands from spi-nor framework and based on SPI_FLASH_DTR_ENABLE
config. If SPI_FLASH_DTR_ENABLE is not defined, do not switch to DTR
mode as it represents that controller does not support DTR. Also do
not reinitilize the SDR/DTR tuning if it is already done.
Also added the functionality to reset the controller when switching
from DTR to STR mode.
Use reset_assert, reset_deassert api's to reset the ospi controller.
In mini U-Boot case as ZYNQMP_FIRMWARE config is disabled, reset the
controller directly using register writes.

The configuration of the chip select in the Cadence QSPI driver is
now determined based on the flags received from SPI-NOR framework.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_ospi_versal.c | 29 +
 drivers/spi/cadence_qspi.c| 69 ---
 drivers/spi/cadence_qspi.h|  7 
 3 files changed, 99 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/cadence_ospi_versal.c 
b/drivers/spi/cadence_ospi_versal.c
index 74994a690d..243de6efaf 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -154,6 +154,35 @@ int cadence_qspi_versal_set_dll_mode(struct udevice *dev)
return -ENOTSUPP;
 }
 
+int cadence_spi_versal_ctrl_reset(struct cadence_spi_priv *priv)
+{
+   int ret;
+
+   if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+   /* Assert ospi controller */
+   ret = reset_assert(priv->resets->resets);
+   if (ret)
+   return ret;
+
+   udelay(10);
+
+   /* Deassert ospi controller */
+   ret = reset_deassert(priv->resets->resets);
+   if (ret)
+   return ret;
+   } else {
+   /* Assert ospi controller */
+   setbits_le32((u32 *)OSPI_CTRL_RST, 1);
+
+   udelay(10);
+
+   /* Deassert ospi controller */
+   clrbits_le32((u32 *)OSPI_CTRL_RST, 1);
+   }
+
+   return 0;
+}
+
 #if defined(CONFIG_DM_GPIO)
 int cadence_qspi_versal_flash_reset(struct udevice *dev)
 {
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 32f91825fd..710c4a532d 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -154,7 +154,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
 
/* just to ensure we do once only when speed or chip select change */
priv->qspi_calibrated_hz = hz;
-   priv->qspi_calibrated_cs = spi_chip_select(bus);
+   priv->qspi_calibrated_cs = priv->cs;
 
return 0;
 }
@@ -179,7 +179,7 @@ static int cadence_spi_set_speed(struct udevice *bus, uint 
hz)
  priv->read_delay);
} else if (priv->previous_hz != hz ||
   priv->qspi_calibrated_hz != hz ||
-  priv->qspi_calibrated_cs != spi_chip_select(bus)) {
+  priv->qspi_calibrated_cs != priv->cs) {
/*
 * Calibration required for different current SCLK speed,
 * requested SCLK speed or chip select
@@ -580,6 +580,9 @@ static int cadence_spi_setup_ddrmode(struct udevice *bus)
struct cadence_spi_priv *priv = dev_get_priv(bus);
int ret;
 
+   if (priv->ddr_init)
+   return 0;
+
ret = priv_setup_ddrmode(bus);
if (ret)
return ret;
@@ -590,7 +593,47 @@ static int cadence_spi_setup_ddrmode(struct udevice *bus)
printf("DDR tuning failed with error %d\n", ret);
return ret;
}
-   priv->ddr_init = 1;
+   priv->ddr_init = true;
+
+   return 0;
+}
+
+static int cadence_spi_setup_strmode(struct udevice *bus)
+{
+   struct cadence_spi_priv *priv = dev_get_priv(bus);
+   void *base = priv->regbase;
+   int ret;
+
+   if (!priv->ddr_init)
+   return 0;
+
+   /* Reset ospi controller */
+   ret = cadence_spi_versal_ctrl_reset(priv);
+   if (ret) {
+   printf("Cadence ctrl reset failed err: %d\n", ret);
+   return ret;
+   }
+
+   ret = wait_for_bit_le32(base + CQSPI_REG_CONFIG,
+   BIT(CQSPI_REG_CONFIG_IDLE_LSB),
+   1, CQSPI_TIMEOUT_MS, 0);
+   if (ret) {
+   printf("spi_wait_idle error : 0x%x\n", ret);
+   return ret;
+   }
+
+   cadence_qspi_apb_controller_init(priv);
+   priv->edge_mode = CQSPI_EDGE_MODE_SDR;
+   priv->extra_dummy = 0;
+   priv->previous_hz = 0;
+   priv->qspi_calibrated_hz = 0;
+
+   /* Setup default speed and calibrate */
+   ret = cadence_spi_set_speed(bus, 0);
+   if (ret)
+   return ret;
+
+   priv->ddr_init = false;
 
return 0;
 }
@@ -604,9 +647,22 @@ static int 

[PATCH 13/30] mtd: spi-nor: Check SNOR_F_IO_MODE_EN_VOLATILE only if SFDP is enabled

[Tejas Bhumkar]

From: Ashok Reddy Soma 

With 'commit bebdc237507c ("mtd: spi-nor: Parse SFDP SCCR Map")', support
for spi_nor_parse_sccr is added under SFDP. But the flag
SNOR_F_IO_MODE_EN_VOLATILE in spi_nor_octal_dtr_enable is always
checked. Check this flag only if SPI_FLASH_SFDP_SUPPORT enabled.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 43435e79cc..ccda722df5 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -4252,8 +4252,9 @@ static int spi_nor_octal_dtr_enable(struct spi_nor *nor)
  nor->write_proto == SNOR_PROTO_8_8_8_DTR))
return 0;
 
-   if (!(nor->flags & SNOR_F_IO_MODE_EN_VOLATILE))
-   return 0;
+   if (CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT))
+   if (!(nor->flags & SNOR_F_IO_MODE_EN_VOLATILE))
+   return 0;
 
ret = nor->octal_dtr_enable(nor);
if (ret)
-- 
2.27.0

[PATCH 12/30] mtd: spi-nor: Update erase operation function

[Tejas Bhumkar]

If the system is in a dual parallel configuration, it's necessary to
halve the erase size since the erase command operates on two flashes
simultaneously. When dealing with a dual-stacked configuration,
determine whether the erase offset refers to the top or bottom flash,
and subsequently, adjust the flag for the relevant flash.
Consequently, the argument for the spi_nor_erase_sector function has
been modified from addr to offset.

Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d790116994..43435e79cc 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1078,7 +1078,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
erase_info *instr)
if (nor->addr_width == 3) {
 #ifdef CONFIG_SPI_FLASH_BAR
/* Update Extended Address Register */
-   ret = write_bar(nor, addr);
+   ret = write_bar(nor, offset);
if (ret < 0)
goto erase_err;
 #endif
@@ -1092,7 +1092,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
erase_info *instr)
!(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
ret = spi_nor_erase_chip(nor);
} else {
-   ret = spi_nor_erase_sector(nor, addr);
+   ret = spi_nor_erase_sector(nor, offset);
}
if (ret < 0)
goto erase_err;
-- 
2.27.0

[PATCH 14/30] spi: cadence_qspi: Setup ddr mode in cadence qspi driver

[Tejas Bhumkar]

From: T Karthik Reddy 

To switch the OSPI controller from SDR to DDR mode, the
RX delay should be configured through flash tuning. Begin
by establishing a constant value for the TX delay and then
increase the RX delay by inspecting the flash IDs. To fine-tune
the RX delay, compare the flash IDs with a set of predetermined
"golden" flash IDs. This tuning process is borrowed from the
Linux Cadence driver. Moreover, make the necessary adjustments
in the DDR PHY setup to facilitate the transition from SDR
to DDR mode within the OSPI controller.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 drivers/spi/cadence_ospi_versal.c |  25 +++
 drivers/spi/cadence_qspi.c| 321 +-
 drivers/spi/cadence_qspi.h|  52 +
 drivers/spi/cadence_qspi_apb.c|  33 ++-
 4 files changed, 416 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/cadence_ospi_versal.c 
b/drivers/spi/cadence_ospi_versal.c
index e02a3b3de3..74994a690d 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cadence_qspi.h"
 #include 
 
@@ -129,6 +130,30 @@ int cadence_qspi_apb_wait_for_dma_cmplt(struct 
cadence_spi_priv *priv)
return 0;
 }
 
+static const struct soc_attr matches[] = {
+   { .family = "Versal", .revision = "v2" },
+   { }
+};
+
+/*
+ * cadence_qspi_versal_set_dll_mode checks for silicon version
+ * and set the DLL mode.
+ * Returns 0 in case of success, -ENOTSUPP in case of failure.
+ */
+int cadence_qspi_versal_set_dll_mode(struct udevice *dev)
+{
+   struct cadence_spi_priv *priv = dev_get_priv(dev);
+   const struct soc_attr *attr;
+
+   attr = soc_device_match(matches);
+   if (attr) {
+   priv->dll_mode = CQSPI_DLL_MODE_MASTER;
+   return 0;
+   }
+
+   return -ENOTSUPP;
+}
+
 #if defined(CONFIG_DM_GPIO)
 int cadence_qspi_versal_flash_reset(struct udevice *dev)
 {
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index cc3a54f295..32f91825fd 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -89,11 +89,21 @@ static int spi_calibration(struct udevice *bus, uint hz)
/* Enable QSPI */
cadence_qspi_apb_controller_enable(base);
 
-   /* read the ID which will be our golden value */
-   err = cadence_spi_read_id(priv, 3, (u8 *));
-   if (err) {
-   puts("SF: Calibration failed (read)\n");
-   return err;
+   if (!priv->ddr_init) {
+   /* read the ID which will be our golden value */
+   err = cadence_spi_read_id(priv, CQSPI_READ_ID_LEN, (u8 
*));
+   if (err) {
+   puts("SF: Calibration failed (read)\n");
+   return err;
+   }
+
+   /* Save flash id's for further use */
+   priv->device_id[0] = (u8)idcode;
+   priv->device_id[1] = (u8)(idcode >> 8);
+   priv->device_id[2] = (u8)(idcode >> 16);
+   } else {
+   idcode = priv->device_id[0] | priv->device_id[1] << 8 |
+priv->device_id[2] << 16;
}
 
/* use back the intended clock and find low range */
@@ -109,7 +119,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
 
/* issue a RDID to get the ID value */
-   err = cadence_spi_read_id(priv, 3, (u8 *));
+   err = cadence_spi_read_id(priv, CQSPI_READ_ID_LEN, (u8 *));
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -190,6 +200,20 @@ static int cadence_spi_set_speed(struct udevice *bus, uint 
hz)
return 0;
 }
 
+static int cadence_spi_child_pre_probe(struct udevice *bus)
+{
+   struct spi_slave *slave = dev_get_parent_priv(bus);
+
+   slave->bytemode = SPI_4BYTE_MODE;
+
+   return 0;
+}
+
+__weak int cadence_qspi_versal_set_dll_mode(struct udevice *dev)
+{
+   return -ENOTSUPP;
+}
+
 static int cadence_spi_probe(struct udevice *bus)
 {
struct cadence_spi_plat *plat = dev_get_plat(bus);
@@ -247,6 +271,14 @@ static int cadence_spi_probe(struct udevice *bus)
priv->qspi_is_init = 1;
}
 
+   priv->edge_mode = CQSPI_EDGE_MODE_SDR;
+   priv->dll_mode = CQSPI_DLL_MODE_BYPASS;
+
+   /* Select dll mode */
+   ret = cadence_qspi_versal_set_dll_mode(bus);
+   if (ret == -ENOTSUPP)
+   debug("DLL mode set to bypass mode : %x\n", ret);
+
priv->wr_delay = 50 * DIV_ROUND_UP(NSEC_PER_SEC, priv->ref_clk_hz);
 
/* Versal and Versal-NET use spi calibration to set read delay */
@@ -290,6 +322,279 @@ static int cadence_spi_set_mode(struct udevice *bus, uint 
mode)
return 0;
 }
 
+static int 

[PATCH 11/30] mtd: spi-nor: Send write disable cmd after every write enable

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Write enable(06h) command will be sent to a flash device to
set the write enable latch bit before every program, erase,
write command. After that write disable command (04h) needs
to be sent to clear the write enable latch.

This write_disable() is missing at the majority of the places
in the driver, add it to clear write enable latch.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
Acked-by: Amit Kumar Mahapatra 
---
 drivers/mtd/spi/spi-nor-core.c | 47 +-
 1 file changed, 41 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 454ae6cd4e..d790116994 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -873,6 +873,7 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
 static int clean_bar(struct spi_nor *nor)
 {
u8 cmd, bank_sel = 0;
+   int ret;
 
if (nor->bank_curr == 0)
return 0;
@@ -880,7 +881,11 @@ static int clean_bar(struct spi_nor *nor)
nor->bank_curr = 0;
write_enable(nor);
 
-   return nor->write_reg(nor, cmd, _sel, 1);
+   ret = nor->write_reg(nor, cmd, _sel, 1);
+   if (ret)
+   return ret;
+
+   return write_disable(nor);
 }
 
 static int write_bar(struct spi_nor *nor, u32 offset)
@@ -1070,11 +1075,15 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
erase_info *instr)
nor->spi->flags &= ~SPI_XFER_U_PAGE;
}
}
+   if (nor->addr_width == 3) {
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = write_bar(nor, addr);
-   if (ret < 0)
-   goto erase_err;
+   /* Update Extended Address Register */
+   ret = write_bar(nor, addr);
+   if (ret < 0)
+   goto erase_err;
 #endif
+   }
+
ret = write_enable(nor);
if (ret < 0)
goto erase_err;
@@ -1195,6 +1204,10 @@ static int write_sr_and_check(struct spi_nor *nor, u8 
status_new, u8 mask)
if (ret)
return ret;
 
+   ret = write_disable(nor);
+   if (ret)
+   return ret;
+
ret = read_sr(nor);
if (ret < 0)
return ret;
@@ -1758,13 +1771,18 @@ static int sst26_lock_ctl(struct spi_nor *nor, loff_t 
ofs, uint64_t len, enum lo
if (ctl == SST26_CTL_CHECK)
return 0;
 
+   /* Write latch enable before write operation */
+   ret = write_enable(nor);
+   if (ret)
+   return ret;
+
ret = nor->write_reg(nor, SPINOR_OP_WRITE_BPR, bpr_buff, bpr_size);
if (ret < 0) {
dev_err(nor->dev, "fail to write block-protection register\n");
return ret;
}
 
-   return 0;
+   return write_disable(nor);
 }
 
 static int sst26_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
@@ -2138,7 +2156,7 @@ static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
return ret;
}
 
-   return 0;
+   return write_disable(nor);
 }
 
 /**
@@ -4248,6 +4266,7 @@ static int spi_nor_octal_dtr_enable(struct spi_nor *nor)
 
 static int spi_nor_init(struct spi_nor *nor)
 {
+   u8 sr2;
int err;
 
if (nor->flags & SNOR_F_HAS_PARALLEL)
@@ -4271,6 +4290,22 @@ static int spi_nor_init(struct spi_nor *nor)
write_enable(nor);
write_sr(nor, 0);
spi_nor_wait_till_ready(nor);
+
+   if (JEDEC_MFR(nor->info) == SNOR_MFR_WINBOND) {
+   write_enable(nor);
+   sr2 = 0;
+   err = nor->write_reg(nor,
+SPINOR_OP_WIN_WRSR2, , 1);
+   if (err < 0) {
+   dev_dbg(nor->dev,
+   "error while writing SR-2 register\n");
+   return -EINVAL;
+   }
+   spi_nor_wait_till_ready(nor);
+   }
+   err = write_disable(nor);
+   if (err)
+   return err;
}
 
if (nor->quad_enable) {
-- 
2.27.0

[PATCH 10/30] mtd: spi-nor: program quad enable bit for winbond flashes

[Tejas Bhumkar]

From: T Karthik Reddy 

Added support to program quad enable bit for Winbond flash memory.
Previously, the quad enable function from Spansion was used for
this purpose. However, for Winbond flash memory, the quad
enable bit is configured by programming the Write Status Register-2
(SR-2) rather than the Configuration Register (CR).

Signed-off-by: T Karthik Reddy 
Co-developed-by: Tejas Bhumkar 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 48 ++
 include/linux/mtd/spi-nor.h|  2 ++
 2 files changed, 50 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index ace5da9591..454ae6cd4e 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2141,6 +2141,49 @@ static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
return 0;
 }
 
+/**
+ * winbond_quad_enable() - Set QE bit in status register-2
+ * @nor:   pointer to a 'struct spi_nor'
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int winbond_quad_enable(struct spi_nor *nor)
+{
+   int ret;
+   u8 cr = 0;
+
+   /* Check current Quad Enable bit value. */
+   cr = read_cr(nor);
+   if (cr < 0) {
+   dev_dbg(nor->dev,
+   "error while reading configuration register\n");
+   return -EINVAL;
+   }
+
+   if (cr & SR2_QUAD_EN_BIT1)
+   return 0;
+
+   cr |= SR2_QUAD_EN_BIT1;
+
+   write_enable(nor);
+
+   ret = nor->write_reg(nor, SPINOR_OP_WIN_WRSR2, , 1);
+   if (ret < 0) {
+   dev_dbg(nor->dev,
+   "error while writing configuration register\n");
+   return -EINVAL;
+   }
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret) {
+   dev_dbg(nor->dev,
+   "timeout while writing configuration register\n");
+   return ret;
+   }
+
+   return write_disable(nor);
+}
+
 /**
  * spansion_read_cr_quad_enable() - set QE bit in Configuration Register.
  * @nor:   pointer to a 'struct spi_nor'
@@ -3052,6 +3095,11 @@ static int spi_nor_init_params(struct spi_nor *nor,
case SNOR_MFR_MICRON:
break;
 
+#if defined(CONFIG_SPI_FLASH_WINBOND)
+   case SNOR_MFR_WINBOND:
+   params->quad_enable = winbond_quad_enable;
+   break;
+#endif
default:
 #if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
/* Kept only for backward compatibility purpose. */
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 72206f51ad..34e0aedc24 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -48,6 +48,7 @@
 #define SPINOR_OP_WRSR 0x01/* Write status register 1 byte */
 #define SPINOR_OP_RDSR20x3f/* Read status register 2 */
 #define SPINOR_OP_WRSR20x3e/* Write status register 2 */
+#define SPINOR_OP_WIN_WRSR20x31/* Winbond Write status register 2 */
 #define SPINOR_OP_READ 0x03/* Read data bytes (low frequency) */
 #define SPINOR_OP_READ_FAST0x0b/* Read data bytes (high frequency) */
 #define SPINOR_OP_READ_1_1_2   0x3b/* Read data bytes (Dual Output SPI) */
@@ -187,6 +188,7 @@
 
 /* Status Register 2 bits. */
 #define SR2_QUAD_EN_BIT7   BIT(7)
+#define SR2_QUAD_EN_BIT1   BIT(1)  /* Winbond Quad I/O */
 
 /*
  * Maximum number of flashes that can be connected
-- 
2.27.0

[PATCH 09/30] mtd: spi-nor-ids: Add support for W25Q02NW

[Tejas Bhumkar]

From: Algapally Santosh Sagar 

Add support for Winbond 256MB flash W25Q02NW which supports 4byte
opcodes and also dual and quad read.

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-ids.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index cb39c99fa8..7876874f97 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -519,6 +519,12 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   {
+   INFO("w25q02nw", 0xef8022, 0, 64 * 1024, 4096,
+SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ |
+   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4B_OPCODES |
+   SPI_NOR_MULTI_DIE)
+   },
{ INFO("w25q80", 0xef5014, 0, 64 * 1024,  16, SECT_4K) },
{ INFO("w25q80bl", 0xef4014, 0, 64 * 1024,  16, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("w25q16cl", 0xef4015, 0, 64 * 1024,  32, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
-- 
2.27.0

[PATCH 08/30] mtd: spi-nor: Update block protection flags for flash parts

[Tejas Bhumkar]

From: Venkatesh Yadav Abbarapu 

The block protection flags for Gigadevice, Spansion, and ISSI flash
memory have been modified. Additionally, new flags for
SPI_NOR_OCTAL_DTR_READ and octal DTR page programming have been
introduced for Micron OSPI flashes. Furthermore, the flashes mt35xu01g
and mt35xu02g have been incorporated into the CONFIG_SPI_FLASH_MT35XU
configuration, so that in driver mt35xu512aba_fixups will be applied.

Signed-off-by: Venkatesh Yadav Abbarapu 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-ids.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3cb132dcff..cb39c99fa8 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -122,9 +122,9 @@ const struct flash_info spi_nor_ids[] = {
{INFO("gd25b256", 0xc84019, 0, 64 * 1024, 512,  SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
{INFO("gd25b512", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K |
-   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES | 
SPI_NOR_HAS_TB)},
{INFO("gd55b01g", 0xc8471B, 0, 64 * 1024, 2048, SECT_4K |
-   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES | 
SPI_NOR_HAS_TB)},
{INFO("gd55b02g", 0xc8471C, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25f64", 0xc84317, 0, 64 * 1024, 128,   SECT_4K |
@@ -191,7 +191,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
-SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
+SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES |
+SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
/* adding these 1.8V OSPI flash parts */
{INFO("gd25lx512", 0xc8681A, 0, 64 * 1024, 1024,SECT_4K |
@@ -212,11 +213,11 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("is25lp128",  0x9d6018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ) },
{ INFO("is25lp256",  0x9d6019, 0, 64 * 1024, 512,
-   SECT_4K | SPI_NOR_DUAL_READ) },
+   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_HAS_TB) },
{ INFO("is25lp512",  0x9d601a, 0, 64 * 1024, 1024,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | 
SPI_NOR_HAS_TB) },
{ INFO("is25lp01g",  0x9d601b, 0, 64 * 1024, 2048,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | 
SPI_NOR_HAS_TB) },
{ INFO("is25wp008", 0x9d7014, 0, 64 * 1024,  16, SPI_NOR_QUAD_READ) },
{ INFO("is25wp016", 0x9d7015, 0, 64 * 1024,  32, SPI_NOR_QUAD_READ) },
{ INFO("is25wp032",  0x9d7016, 0, 64 * 1024,  64,
@@ -233,7 +234,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("is25wp01g",  0x9d701b, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25wx256",  0x9d5b19, 0, 128 * 1024, 256,
-   SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | 
SPI_NOR_4B_OPCODES) },
+   SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | 
SPI_NOR_4B_OPCODES |
+   SPI_NOR_HAS_TB) },
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX   /* MACRONIX */
/* Macronix */
@@ -312,11 +314,15 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25ql02g",   0x20ba22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE | SPI_NOR_4B_OPCODES) },
 #ifdef CONFIG_SPI_FLASH_MT35XU
-   { INFO("mt35xl512aba", 0x2c5a1a, 0,  128 * 1024,  512, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ) },
-   { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ) },
+   { INFO("mt35xl512aba", 0x2c5a1a, 0,  128 * 1024,  512,
+   USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) },
+   { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512,
+   USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) },
+   { INFO6("mt35xu01g",  0x2c5b1b, 0x104100, 128 * 1024,  1024,
+   USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | 
SPI_NOR_OCTAL_DTR_READ | 

[PATCH 07/30] spi: mtd: Use split reads if multi-die flag is set

[Tejas Bhumkar]

From: T Karthik Reddy 

Some flash devices have multiple dies in it & has die cross over
issue. When SPI_NOR_MULTI_DIE flag is set in flash id table use
it to enable split reads to avoid above issue. Define SPI_NOR_MULTI_DIE
new flag to flash id flags. Remove SPI_FLASH_SPLIT_READ config and
related code from the zynq and zynqmp qspi drivers as it is redundant.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/sf_internal.h  | 1 +
 drivers/mtd/spi/spi-nor-core.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 9c09f97ce2..2cbdea60b0 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -70,6 +70,7 @@ struct flash_info {
 #define SPI_NOR_OCTAL_READ BIT(16) /* Flash supports Octal Read */
 #define SPI_NOR_OCTAL_DTR_READ BIT(17) /* Flash supports Octal DTR Read */
 #define SPI_NOR_OCTAL_DTR_PP   BIT(18) /* Flash supports Octal DTR page 
program */
+#define SPI_NOR_MULTI_DIE  BIT(19) /* Flash has multi dies & need split 
reads*/
 };
 
 extern const struct flash_info spi_nor_ids[];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 63f78baaf4..ace5da9591 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -4485,6 +4485,9 @@ int spi_nor_scan(struct spi_nor *nor)
if (info->flags & SPI_NOR_NO_ERASE)
mtd->flags |= MTD_NO_ERASE;
 
+   if (info->flags & SPI_NOR_MULTI_DIE)
+   nor->spi->multi_die = true;
+
nor->page_size = params.page_size;
mtd->writebufsize = nor->page_size;
 
-- 
2.27.0

[PATCH 06/30] mtd: spi-nor: Enable DTR octal flash program

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Define a flag SPI_NOR_OCTAL_DTR_PP and if enabled in spi-nor-ids table,
enable octal DTR page program in the framework.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/sf_internal.h  | 1 +
 drivers/mtd/spi/spi-nor-core.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index d3ef69ec74..9c09f97ce2 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -69,6 +69,7 @@ struct flash_info {
 #define SPI_NOR_HAS_SST26LOCK  BIT(15) /* Flash supports lock/unlock via BPR */
 #define SPI_NOR_OCTAL_READ BIT(16) /* Flash supports Octal Read */
 #define SPI_NOR_OCTAL_DTR_READ BIT(17) /* Flash supports Octal DTR Read */
+#define SPI_NOR_OCTAL_DTR_PP   BIT(18) /* Flash supports Octal DTR page 
program */
 };
 
 extern const struct flash_info spi_nor_ids[];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index f6e7592458..63f78baaf4 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3026,7 +3026,8 @@ static int spi_nor_init_params(struct spi_nor *nor,
 * Since xSPI Page Program opcode is backward compatible with
 * Legacy SPI, use Legacy SPI opcode there as well.
 */
-   if (CONFIG_IS_ENABLED(SPI_FLASH_DTR_ENABLE)) {
+   if (CONFIG_IS_ENABLED(SPI_FLASH_DTR_ENABLE) && info->flags & 
SPI_NOR_OCTAL_DTR_PP) {
+   params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;

spi_nor_set_pp_settings(>page_programs[SNOR_CMD_PP_8_8_8_DTR],
SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
}
-- 
2.27.0

[PATCH 05/30] mtd: spi-nor: Add support for cross die read in dual flash configuration

[Tejas Bhumkar]

From: Ashok Reddy Soma 

In a dual parallel configuration, halve the read offset.
Determine whether the read offset points to the lower or
upper flash in a dual stacked configuration and set the
corresponding flags accordingly.

Include support for cases where the read involves an odd
number of bytes.

Extend support for cross-die reads in flash memory devices
that contain multiple dies within them.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Michal Simek 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 61 ++
 include/spi.h  |  3 +-
 2 files changed, 56 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index e505648e5d..f6e7592458 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1503,11 +1503,8 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t 
from, size_t len,
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
u32 offset = from;
-   u32 stack_shift = 0;
-   u32 read_len = 0;
-   u32 rem_bank_len = 0;
-   u8 bank;
-   u8 is_ofst_odd = 0;
+   u32 bank_size, stack_shift = 0, read_len = 0, rem_bank_len = 0;
+   u8 bank, cur_bank, nxt_bank, is_ofst_odd = 0;
 
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
 
@@ -1541,6 +1538,40 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t 
from, size_t len,
}
}
 
+   if (nor->addr_width == 4) {
+   /*
+* Some flash devices like N25Q512 have multiple dies
+* in it. Read operation in these devices is bounded
+* by its die segment. In a continuous read, across
+* multiple dies, when the last byte of the selected
+* die segment is read, the next byte read is the
+* first byte of the same die segment. This is Die
+* cross over issue. So to handle this issue, split
+* a read transaction, that spans across multiple
+* banks, into one read per bank. Bank size is 16MB
+* for single and dual stacked mode and 32MB for dual
+* parallel mode.
+*/
+   if (nor->spi && nor->spi->multi_die) {
+   bank_size = SZ_16M;
+   if (nor->flags & SNOR_F_HAS_PARALLEL)
+   bank_size <<= 1;
+   cur_bank = offset / bank_size;
+   nxt_bank = (offset + len) / bank_size;
+   if (cur_bank != nxt_bank)
+   rem_bank_len = (bank_size *
+   (cur_bank + 1)) -
+   offset;
+   else
+   rem_bank_len = (mtd->size >>
+   stack_shift) -
+   offset;
+   } else {
+   rem_bank_len = (mtd->size >> stack_shift) -
+   offset;
+   }
+   }
+
if (nor->flags & SNOR_F_HAS_PARALLEL)
offset /= 2;
 
@@ -1552,6 +1583,15 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t 
from, size_t len,
 #endif
}
 
+   if (len < rem_bank_len)
+   read_len = len;
+   else
+   read_len = rem_bank_len;
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret)
+   goto read_err;
+
ret = nor->read(nor, offset, read_len, buf);
if (ret == 0) {
/* We shouldn't see 0-length reads */
@@ -1561,8 +1601,15 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t 
from, size_t len,
if (ret < 0)
goto read_err;
 
-   *retlen += ret;
-   buf += ret;
+   if (is_ofst_odd == 1) {
+   memcpy(buf, (buf + 1), (len - 1));
+   *retlen += (ret - 1);
+   buf += ret - 1;
+   is_ofst_odd = 0;
+   } else {
+   *retlen += ret;
+   buf += ret;
+   }
from += ret;
len -= ret;
}
diff --git a/include/spi.h b/include/spi.h
index eb015ecbf5..9014066ee3 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -165,7 +165,7 @@ struct spi_slave {
unsigned int max_write_size;
void 

[PATCH 04/30] mtd: spi-nor: Enable mt35xu512aba_fixups for all mt35xx flashes

[Tejas Bhumkar]

From: Ashok Reddy Soma 

Enable mt35xu512aba_fixups for all mt35 series flashes to work
in DTR mode, and return after nor->fixups is updated, otherwise
it will get overwritten with macronix_octal_fixups.
This flash works in DTR mode only if CONFIG_SPI_FLASH_MT35XU
is enabled and SPI_NOR_OCTAL_DTR_READ flag is set in id table.

Additionally, a new flag, "SPI_XFER_SET_DDR," has been introduced
to instruct the Ospi controller driver to switch to DDR mode.

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 8 +++-
 include/spi.h  | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 8949dab548..e505648e5d 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3991,6 +3991,7 @@ static int spi_nor_micron_octal_dtr_enable(struct spi_nor 
*nor)
if (ret)
return ret;
 
+   nor->spi->flags |= SPI_XFER_SET_DDR;
buf = SPINOR_MT_OCT_DTR;
op = (struct spi_mem_op)
SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
@@ -4305,8 +4306,13 @@ void spi_nor_set_fixups(struct spi_nor *nor)
 #endif
 
 #ifdef CONFIG_SPI_FLASH_MT35XU
-   if (!strcmp(nor->info->name, "mt35xu512aba"))
+   if (!strcmp(nor->info->name, "mt35xu512aba") ||
+   !strcmp(nor->info->name, "mt35xl512aba") ||
+   !strcmp(nor->info->name, "mt35xu01g") ||
+   !strcmp(nor->info->name, "mt35xu02g")) {
nor->fixups = _fixups;
+   return;
+   }
 #endif
 
 #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
diff --git a/include/spi.h b/include/spi.h
index 6bc8808bb9..eb015ecbf5 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -171,6 +171,7 @@ struct spi_slave {
 #define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
 #define SPI_XFER_U_PAGEBIT(4)
 #define SPI_XFER_STACKED   BIT(5)
+#define SPI_XFER_SET_DDR   BIT(6)
/*
 * Flag indicating that the spi-controller has multi chip select
 * capability and can assert/de-assert more than one chip select
-- 
2.27.0

[PATCH 03/30] arm64: versal: Enable defconfig for Micron octal flashes

[Tejas Bhumkar]

The Micron MT35 series octal flashes can be activated
through the configuration option CONFIG_SPI_FLASH_MT35XU.
To ensure their detection, enable this option in the
default defconfig for octal flashes.

Signed-off-by: Tejas Bhumkar 
---
 configs/xilinx_versal_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_virt_defconfig 
b/configs/xilinx_versal_virt_defconfig
index 6a2c03ccdd..ec7caacca0 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -95,6 +95,7 @@ CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_ZYNQ_SDHCI_MIN_FREQ=10
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
-- 
2.27.0

[PATCH 02/30] mtd: spi-nor-core: Set dummy buswidth equal to data buswidth

[Tejas Bhumkar]

From: T Karthik Reddy 

In current implementation dummy buswidth is set equal to address
buswidth. In case of quad spi (mode 1-1-4), where address width is 1
the dummy bytes will be calculated to 1(8 dummy cycles) and dummy
buswidth is set to 1. Due to this, the controller driver will introduce
8 dummy cycles on data line(D0) during read operation.

But since we are using 4 data lines in case of qspi, we need to change
this dummy bus width to 4. This will make dummy bytes to 4 inplace of 1.
This will be taken care in controller driver by dividing with dummy
buswidth again as in below code, which makes dummy cycles to 8 as
earlier.

dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;

So with this change dummy cycles will be on all data lines(D0-D3) and it
is taken care for all the configurations(single, dual, quad and octal).

Signed-off-by: Ashok Reddy Soma 
Signed-off-by: T Karthik Reddy 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 473d9f41f3..8949dab548 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -260,7 +260,7 @@ void spi_nor_setup_op(const struct spi_nor *nor,
op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
 
if (op->dummy.nbytes)
-   op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+   op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto);
 
if (op->data.nbytes)
op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
-- 
2.27.0

[PATCH 01/30] mtd: spi-nor: Add config to enable flash DTR

[Tejas Bhumkar]

From: T Karthik Reddy 

The spi-nor framework will set up the flash parameters by
reading the flash id table flags, which include cmd opcodes,
address width, dummy bytes, and bus width. In case, flash
supports octal DTR mode and the controller does not support
the DTR. There is no process to switch back to SDR mode.
To avoid this issue, create a Kconfig option SPI_FLASH_DTR_ENABLE
to explicitly specify to enable/disable flash DTR support.
This config is disabled by default.
Do not initialize the mt35xu512aba post sfdp fixups unless
SPI_FLASH_DTR_ENABLE is enabled to avoid configuring DTR.

Signed-off-by: T Karthik Reddy 
Co-developed-by: Tejas Bhumkar 
Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/Kconfig|  7 +++
 drivers/mtd/spi/spi-nor-core.c | 12 +---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 732b076045..e0898074a2 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -202,6 +202,13 @@ config SPI_FLASH_MT35XU
 because the fixup hooks for this flash add extra size overhead. Boards
 that don't use the flash can disable this to save space.
 
+config SPI_FLASH_DTR_ENABLE
+   bool "Enable Flash DTR support"
+   help
+ Select this config to enable DTR mode by spi-nor framework.
+ This config provides an option to explicitly enable/disable the DTR
+ support even though the flash id flags specify flash supports DTR 
mode.
+
 config SPI_FLASH_SST
bool "SST SPI flash support"
help
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 5c3ffc80eb..473d9f41f3 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2962,7 +2962,8 @@ static int spi_nor_init_params(struct spi_nor *nor,
  SNOR_PROTO_1_1_8);
}
 
-   if (info->flags & SPI_NOR_OCTAL_DTR_READ) {
+   if (CONFIG_IS_ENABLED(SPI_FLASH_DTR_ENABLE) &&
+   info->flags & SPI_NOR_OCTAL_DTR_READ) {
params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;

spi_nor_set_read_settings(>reads[SNOR_CMD_READ_8_8_8_DTR],
  0, 20, SPINOR_OP_READ_FAST,
@@ -2978,8 +2979,10 @@ static int spi_nor_init_params(struct spi_nor *nor,
 * Since xSPI Page Program opcode is backward compatible with
 * Legacy SPI, use Legacy SPI opcode there as well.
 */
-   spi_nor_set_pp_settings(>page_programs[SNOR_CMD_PP_8_8_8_DTR],
-   SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
+   if (CONFIG_IS_ENABLED(SPI_FLASH_DTR_ENABLE)) {
+   
spi_nor_set_pp_settings(>page_programs[SNOR_CMD_PP_8_8_8_DTR],
+   SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
+   }
 
if (info->flags & SPI_NOR_QUAD_READ) {
params->hwcaps.mask |= SNOR_HWCAPS_PP_1_1_4;
@@ -4011,6 +4014,9 @@ static void mt35xu512aba_default_init(struct spi_nor *nor)
 static void mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor,
 struct spi_nor_flash_parameter *params)
 {
+   if (!CONFIG_IS_ENABLED(SPI_FLASH_DTR_ENABLE))
+   return;
+
/* Set the Fast Read settings. */
params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
spi_nor_set_read_settings(>reads[SNOR_CMD_READ_8_8_8_DTR],
-- 
2.27.0

[PATCH 00/30] Fix issues with QSPI and OSPI compare failures

[Tejas Bhumkar]

A set of patches has been developed to resolve concerns regarding 
data integrity failures in QSPI and OSPI for the Versal, Versal NET, 
Zynq, and ZynqMP platforms.

The series has undergone testing with flashes on the default setup, 
and comprehensive testing is currently underway to test the series 
with all available flash parts.

These patches are built upon the v5 series, which can be found at 
the following link: 
https://lore.kernel.org/all/20231201031839.239567-1-venkatesh.abbar...@amd.com/

Algapally Santosh Sagar (1):
  mtd: spi-nor-ids: Add support for W25Q02NW

Ashok Reddy Soma (10):
  mtd: spi-nor: Enable mt35xu512aba_fixups for all mt35xx flashes
  mtd: spi-nor: Add support for cross die read in dual flash
configuration
  mtd: spi-nor: Enable DTR octal flash program
  mtd: spi-nor: Send write disable cmd after every write enable
  mtd: spi-nor: Check SNOR_F_IO_MODE_EN_VOLATILE only if SFDP is enabled
  spi: cadence_qspi: Set tshsl_ns to at least one sclk_ns
  spi: cadence_qspi: Clean up registers in init
  spi: cadence_qspi: Initialize read and write watermark registers
  spi: cadence_qspi: Enable ECO bit for higher frequencies
  spi: cadence_qspi: Write aligned byte length to ahbbase

T Karthik Reddy (9):
  mtd: spi-nor: Add config to enable flash DTR
  mtd: spi-nor-core: Set dummy buswidth equal to data buswidth
  spi: mtd: Use split reads if multi-die flag is set
  mtd: spi-nor: program quad enable bit for winbond flashes
  spi: cadence_qspi: Setup ddr mode in cadence qspi driver
  spi: cadence-qspi: Switch SDR/DTR using SPI_FLASH_DTR_ENABLE config
  spi: cadence_ospi_versal: ospi ddr changes in cadence ospi versal
driver
  spi: cadence_qspi: Add spi mem dtr support ops
  mtd: spi-nor: Add block protection support for micron flashes

Tejas Bhumkar (5):
  arm64: versal: Enable defconfig for Micron octal flashes
  mtd: spi-nor: Update erase operation function
  spi: cadence_qspi: Fix versal ospi indirect write timed out issue
  arm64: versal: Enable soft reset support for xspi flashes
  arm64: versal: Enable octal DTR mode

Venkatesh Yadav Abbarapu (5):
  mtd: spi-nor: Update block protection flags for flash parts
  mtd: spi-nor: Add support for locking on Macronix nor flashes
  mtd: spi-nor: Add support for locking on ISSI nor flashes
  mtd: spi-nor: Add support for locking on GIGADEVICE nor flashes
  mtd: spi-nor: Add support for locking on Spansion nor flashes

 configs/xilinx_versal_virt_defconfig |4 +
 drivers/mtd/spi/Kconfig  |7 +
 drivers/mtd/spi/sf_internal.h|8 +
 drivers/mtd/spi/spi-nor-core.c   | 2028 +++---
 drivers/mtd/spi/spi-nor-ids.c|   40 +-
 drivers/spi/cadence_ospi_versal.c|   77 +-
 drivers/spi/cadence_qspi.c   |  403 -
 drivers/spi/cadence_qspi.h   |   71 +
 drivers/spi/cadence_qspi_apb.c   |  107 +-
 include/linux/mtd/spi-nor.h  |   22 +
 include/spi.h|4 +-
 11 files changed, 2545 insertions(+), 226 deletions(-)

-- 
2.27.0

Re: [PATCH 00/21] Qualcomm generic board support

[ff]

Le 5 déc. 2023 à 13:48, Daniel Thompson  a écrit :

On Tue, Dec 05, 2023 at 10:36:28AM +, ff wrote:
Le 5 déc. 2023 à 10:46, Sumit Garg  a écrit :

+ U-boot custodians list

On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
 wrote:

On 05/12/2023 08:13, Sumit Garg wrote:
@DT bindings maintainers,

Given the ease of maintenance of DT bindings within Linux kernel
source tree, I don't have a specific objection there. But can we
ease DTS testing for firmware/bootloader projects by providing a
versioned release package for DT bindings? Or if someone else
has a better idea here please feel free to chime in.

This doesn't work for you?:

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Thanks, this is certainly a good step which I wasn't aware of.
Further simplification can be done to decouple devicetree source
files from DT bindings.

Why?

I suppose you are already aware that Linux DTS files are a subset of
what could be supported by devicetree schemas. There can be
firmware/bootloader specific properties (one example being [1])
which Linux kernel can simply ignore. Will you be willing to add all
of those DT properties to Linux DTS files and maintain them?

A pre-existing effort to solve the same problem as [1] is System
Device Tree, discussed in the context of Linaro supported OpenAMP
project. It is not just about cherry picking devices that have
bindings in Linux but also information about clock and power domains
or devices that are not seen by Linux.  It is obvious that the
resulting bindings should be maintained upstream in the DT repo
regardless of the communities adopted solution.

This seems to be artificially linking two topics: system DT and DT
schema validation within u-boot. They are somewhat related but one of
not a precondition of the other.

Agreed. I am mentioning this because it relates to binding
and conformance testing:   DT consumers such as OP-TEE , OSes and
hypervisors should be considered equally as U-Boot and Linux.
Hence it makes sense that all those are decoupled from any
consumer and live « standalone ».


However, DT bindings are something which should be common, the
hardware description of a device should be universal. IMO, splitting
DT bindings alone would ease the compliance process for u-boot
drivers in quite similar manner to Linux drivers.

I remember a discussion with ST on that topic related to Framebuffer.
U-Boot can need a very different representation of the same device to
use it while Linux need an in-depth description of all shaders and «
stuff » (another reason why [1] is addressing only a portion of the
problem) So even if there is a single frame buffer binding, there
should be two (at least) conformance tests.

I don't follow this, for two reasons.

1. DT describes the hardware, not how it is driven. Having a relationship
  between u-boot and linux DTs with different representation would
  imply that the hardware changes between u-boot and the kernel.

2. Even if we were to accept that there must be two device tree instances
  (beyond transient workarounds for missing features), why would there
  need to be two conformance tests rather than one conformance test run
  on the two DTs?

Let’s say U-Boot only cares and use legacy SGVA frame buffer, while Linux
 community only cares and use the full fledged GPU. You end-up with two
communities maintaining the conformance test part it cares/need.
Isn’t splitting the tests responsibilities a way to get people feel
more « empowered » and thus more active?


Daniel.

Re: [PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
 wrote:
>
> On 05/12/2023 10:45, Sumit Garg wrote:
> > + U-boot custodians list
> >
> > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
> >  wrote:
> >>
> >> On 05/12/2023 08:13, Sumit Garg wrote:
> > @DT bindings maintainers,
> >
> > Given the ease of maintenance of DT bindings within Linux kernel
> > source tree, I don't have a specific objection there. But can we ease
> > DTS testing for firmware/bootloader projects by providing a versioned
> > release package for DT bindings? Or if someone else has a better idea
> > here please feel free to chime in.
> 
>  This doesn't work for you?:
> 
>  https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> >>>
> >>> Thanks, this is certainly a good step which I wasn't aware of. Further
> >>> simplification can be done to decouple devicetree source files from DT
> >>> bindings.
> >>
> >> Why?
> >
> > I suppose you are already aware that Linux DTS files are a subset of
> > what could be supported by devicetree schemas. There can be
> > firmware/bootloader specific properties (one example being [1]) which
> > Linux kernel can simply ignore. Will you be willing to add all of
> > those DT properties to Linux DTS files and maintain them?
>
> We already added them and we already maintain them. DTS describes the
> hardware, not the OS-subset of the hardware.

Let look at some numbers if your statement is justified or not for the
example I gave:

u-boot$ git grep -nr bootph-* arch/arm* | wc -l
4079

linux$ git grep -nr bootph-* arch/arm* | wc -l
267

It looks like there is always going to be a catch up game regarding DT
properties which either Linux kernel or u-boot or any other
firmware/bootloader project don't care about.

>
> >
> > However, DT bindings are something which should be common, the
> > hardware description of a device should be universal. IMO, splitting
>
> Both DT bindings and DTS should be common. I don't see the difference.

If we really care about DTS to be common then the contribution model
has to change where there is a single repo hosting DT bindings and
DTS. All other projects whether it is Linux kernel or u-boot or any
other OS/firmware/bootloader are just consuming DTS files from that
single repo. I suppose this is something that Linux DT maintainers
have objected to in the past for ease of maintenance. I am not sure if
you folks are willing to change that stance.

>
> > DT bindings alone would ease the compliance process for u-boot drivers
> > in quite similar manner to Linux drivers.
> >
> > [1] 
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml
> >
> >>
> >>> AFAIK, DT bindings should be forwards and backwards
> >>> compatible.
> >>
> >> The same with DTS.
> >>
> >>> So if you pick up DTS or DTB from any project tree
> >>> (upstream kernel or stable kernel or u-boot) then DT schema validation
> >>> would ensure that corresponding DTS or DTB doesn't regress the DT
> >>> bindings.
> >>
> >> And why is this argument to decouple DTS from bindings?
> >>
> >
> > See above.
>
> It's not really explained there. You can pick up DTS from any project
> and validate it against the repo Rob mentioned or against kernel.
> Whether DTS is in that repo or not, does not matter for your validation.
>

It is similar to your earlier argument to use the whole mainline
kernel repo. What is the real benefit to keep DT bindings and DTS
together when every project has to maintain a copy of DTS in its own
source tree? It will be just a source of confusion for developers:
- One DTS coming from devicetree-rebasing repo
- One DTS coming from local project

-Sumit

Re: [PATCH v2 1/3] binman: etype: dm: Add entry type for TI DM

[Neha Malcom Francis]

Hi Simon,

On 06/12/23 09:24, Simon Glass wrote:

On Tue, 5 Dec 2023 at 02:42, Neha Malcom Francis  wrote:


K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.

The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin

Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.

Signed-off-by: Neha Malcom Francis 
Reviewed-by: Andrew Davis 
---
  Makefile|  1 +
  tools/binman/entries.rst| 14 ++
  tools/binman/etype/ti_dm.py | 22 ++
  tools/binman/ftest.py   |  7 +++
  tools/binman/test/225_ti_dm.dts | 13 +
  5 files changed, 57 insertions(+)
  create mode 100644 tools/binman/etype/ti_dm.py
  create mode 100644 tools/binman/test/225_ti_dm.dts



Reviewed-by: Simon Glass 

Is there a doc/ update somewhere about TI_DM ?



Yes, it's patch 3/3 in this series.


Regards,
Simon


--
Thanking You
Neha Malcom Francis

Re: [PATCH v2 15/18] fdt: Allow the devicetree to come from a bloblist

[Simon Glass]

Hi Ilias,

On Mon, 4 Dec 2023 at 23:22, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
> We did discuss this in OSFC but perhaps you forgot.  The discussion
> was based on the mail here [0].

Perhaps I did? Or perhaps we had a different understanding of it?

>
> On Tue, 5 Dec 2023 at 02:52, Simon Glass  wrote:
> >
> > Hi Raymond,
> >
> > On Mon, 4 Dec 2023 at 12:25, Raymond Mao  wrote:
> > >
> > > Hi Simon,
> > >
> > > When `OF_BOARD` is defined, the FDT should be from one of  the 
> > > board-specific mechanisms:
> > > 1. FDT from a bloblist via boot args
> > > 2. FDT in memory
> > > I don't think we need a new build option to distinguish these two, since 
> > > it can be done in runtime by checking whether the boot args follow the FW 
> > > Handoff spec conventions and the FDT exists in the bloblist.
> >
> > No, I would really like this to be deterministic, so we can fail if
> > something goes wrong. The bloblist should be 'declared' as the way to
> > boot, for a board.
>
> We *are* deterministic. I am just going to repeat what we discussed in
> OSFC for completeness.
> OF_BLOBLIST makes little sense because we are not going to add a
> Kconfig per blolblist entry.
> I haven't looked at what the patch does yet but the idea was really simple.
> - Under OF_BOARD (which can arguably be renamed to OF_PREVIOUS_STAGE
> or something like that)  if CONFIG_BLOB is enabled we scan for a
> bloblist
> - If CONFIG_BLOB is enabled but no bloblist is provided we fail the boot
> - If CONFIG_BLOB is not enabled we do what we did up to now, maybe
> with a message that this is going to be obsoleted once enough boards
> migrate to a bloblist
>
> IOW if support for a bloblist is enabled we expect to find one from
> the previous bootloader. I've lost count of how many times I repeated
> this, but here it goes again
> The device tree can come
> - From u-boot
> - From a previous stage loader *somehow* (eg. passed on a bloblist,
> passed on a register, read from an EEPROM etc)
>
> We should keep that distinction and create subcategories for the
> 'comes from a previous stage loader', rather than adding arbitrary
> config options which only confuse people

I don't know why you are so frustrated about this. This patch does not
even do what you have listed above, so far as I can tell.

We have:
- OF_HAS_PRIOR_STAGE which indicates that U-Boot is not the first phase
- OF_BOARD which indicates that the board can do anything it likes
- BLOBLIST which indicates that there is a bloblist

I proposed adding:
- OF_BLOBLIST which indicates that U-Boot gets the DT from the bloblist

I understood that your intention OF_BOARD would go away since there
are almost no cases that need it. I was skeptical it could be done but
I definitely agreed (and still do) that it would be great if that
could go away, as we would not need OF_BLOBLIST since OF_BOARD would
effectively mean the same thing.

But when I look at this patch, that is not what is happening. In fact,
there is no indication that the DT came from the bloblist. U-Boot will
just report 'devicetree: board'. We must say where it came from.

The other thing missing here is SPL. The bloblist is designed such
that it can be set up in any phase of U-Boot, then is passed to
following phases. So using IS_ENABLED(BLOBLIST) doesn't do what we
need. As I noted, it breaks sandbox_spl. What happens if a board wants
to use bloblist in SPL but doesn't want the SPL DT to come from a
prior stage? What happens if SPL wants doesn't want to pass the U-Boot
DT through to U-Boot in the bloblist? It is all just horribly
confusing.

So I believe, in fact, that we cannot get rid of OF_BOARD now, and
perhaps for quite a long time. There is another discussion about
Qualcomm where they want a gzipped DT attached to the end of U-Boot,
for example. Perhaps the key problem with this patch is that it would
ensure that OF_BOARD sticks around, since it means both a) Get the DT
from bloblist if BLOBLIST; b) Get the DT from a board-specific
mechanism if !BLOBLIST. That is not what we discussed.

Why not just take my original patch and work from there? It will save
a lot of time. We can then progressively migrate boards from OF_BOARD
to OF_BLOBLIST and then perhaps one day remove OF_BOARD (I remain
skeptical, but hopeful). The whole 'standard passage' thing [1] was
carefully thought out *two years ago* and (I believe) dealt with all
of the issues above.

For now, we should apply the patches which bring in the spec changes,
so we can figure out the rest of it. I have added my review tag for
those.

Regards,
SImon
>
> Regards
> /Ilias
> >
> > If in the future all boards a reusing bloblist for this feature, then
> > sure, we can drop it. But we have things like rpi which do their own
> > thing.
> >
> > > If it fulfills the above conditions, we can take the FDT from bloblist, 
> > > otherwise from the predefined memory address.
> > > This is fully backward compatible without adding a new build option.
> >
> > Again, we need to obtain the 

Re: [PATCH v4 0/4] bootflow: bootmeth_efi: Fix network efi boot.

[Simon Glass]

Hi Shantur,

On Tue, 5 Dec 2023 at 04:13, Shantur Rathore  wrote:
>
> Hi Simon,
>
> On Tue, Dec 5, 2023 at 12:52 AM Simon Glass  wrote:
> >
> > Hi Shantur,
> >
> > On Mon, 4 Dec 2023 at 05:38, Shantur Rathore  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, Nov 19, 2023 at 4:56 PM Shantur Rathore  wrote:
> > > >
> > > >
> > > > Currently bootmeth_efi crashes while doing a network (dhcp) boot.
> > > > This patch series fixes issues and both network and disk boot works.
> > > >
> > > How can I help to get this patch series merged in?
> >
> > You can check patchwork [1] to see who it is assigned to. I don't see
> > it in my queue though.
> >
> It's with Tom Rini I believe but with status Needs Review / ACK.
>
> https://patchwork.ozlabs.org/project/uboot/list/?series=382855

OK, well it has a review so that tag may be out-of-date.

+Tom Rini

Regards,
SImon

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Simon Glass]

Hi Ahmad,

On Tue, 5 Dec 2023 at 04:48, Ahmad Fatoum  wrote:
>
> Hello Simon,
>
> On 02.12.23 04:54, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> >
> > Signed-off-by: Simon Glass 
>
> kernel_noload support is now in barebox next branch and I tested this
> series against it:
>
> Tested-by: Ahmad Fatoum  # barebox
>

OK great thank you.

> > +"""Build a FIT containing a lot of devicetree files
> > +
> > +Usage:
> > +make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> > +-f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> > +/tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> > +
> > +Creates a FIT containing the supplied kernel and a directory containing the
> > +devicetree files.
> > +
> > +Use -E to generate an external FIT (where the data is placed after the
> > +FIT data structure). This allows parsing of the data without loading
> > +the entire FIT.
> > +
> > +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> > +zstd algorithms.
> > +
> > +The resulting FIT can be booted by bootloaders which support FIT, such
> > +as U-Boot, Linuxboot, Tianocore, etc.
>
> Feel free to add barebox to the list. Did you check whether Linuxboot and
> Tianocore support kernel_noload?

Only what I was told by people in those projects. They may not even
look at the load address, but I am not an expert on that.

>
> > +fsw.property_u32('load', 0)
> > +fsw.property_u32('entry', 0)
>
> I still think load and entry dummy values are confusing and should be dropped.

This is what the spec requires at present. But I agree we should
change it. I will dig into that at some point to see what is needed.

>
> > +with fsw.add_node(f'fdt-{seq}'):
> > +# Get the compatible / model information
> > +with open(fname, 'rb') as inf:
> > +data = inf.read()
> > +fdt = libfdt.FdtRo(data)
> > +model = fdt.getprop(0, 'model').as_str()
> > +compat = fdt.getprop(0, 'compatible')
> > +
> > +fsw.property_string('description', model)
> > +fsw.property_string('type', 'flat_dt')
> > +fsw.property_string('arch', arch)
> > +fsw.property_string('compression', compress)
> > +fsw.property('compatible', bytes(compat))
> > +
> > +with open(fname, 'rb') as inf:
> > +compressed = compress_data(inf, compress)
> > +fsw.property('data', compressed)
> > +return model, compat
>
> After Doug's elaboration, extracting multiple compatibles is fine by me.

OK good.

Regards,
Simon

Re: [PATCH 06/14] fastboot: Change fastboot_buf_addr to an address

[Simon Glass]

Hi Mattijs,

On Tue, 5 Dec 2023 at 02:16, Mattijs Korpershoek
 wrote:
>
> Hi Simon,
>
> Thank you for your patch.
>
> On dim., déc. 03, 2023 at 17:31, Simon Glass  wrote:
>
> > Given the name of this variable, it should be an address, not a
> > pointer. Update this, to make it easier to use with sandbox.
> >
> > Signed-off-by: Simon Glass 
>
> Tested that I could reflash AOSP on the Khadas VIM 3 board.
>
> Tested-by: Mattijs Korpershoek  # on vim3
>
> Reviewed-by: Mattijs Korpershoek 
>
> Some small nit/question below.
>
> > ---
> >
> >  cmd/fastboot.c|  2 +-
> >  drivers/fastboot/fb_command.c | 13 -
> >  drivers/fastboot/fb_common.c  | 15 ---
> >  include/fastboot-internal.h   |  2 +-
> >  include/fastboot.h|  6 +++---
> >  5 files changed, 17 insertions(+), 21 deletions(-)
> >
> > diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> > index c3c19231c988..792e83d372c3 100644
> > --- a/cmd/fastboot.c
> > +++ b/cmd/fastboot.c
> > @@ -159,7 +159,7 @@ NXTARG:
> >   return CMD_RET_USAGE;
> >   }
> >
> > - fastboot_init((void *)buf_addr, buf_size);
> > + fastboot_init(buf_addr, buf_size);
> >
> >   if (!strcmp(argv[1], "udp"))
> >   return do_fastboot_udp(argc, argv, buf_addr, buf_size);
> > diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> > index 5fcadcdf503d..ec030886dbb8 100644
> > --- a/drivers/fastboot/fb_command.c
> > +++ b/drivers/fastboot/fb_command.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -252,7 +253,7 @@ void fastboot_data_download(const void *fastboot_data,
> >   return;
> >   }
> >   /* Download data to fastboot_buf_addr */
> > - memcpy(fastboot_buf_addr + fastboot_bytes_received,
> > + memcpy(map_sysmem(fastboot_buf_addr, 0) + fastboot_bytes_received,
> >  fastboot_data, fastboot_data_len);
>
> I'm a little confused on why there is no call of unmap_sysmem() here but
> that seems to be the case for plenty other callers of map_sysmem().
>
> From what I've seen, in the sandbox unmap_sysmem() is a no-oop, but what
> about other architectures ?

Yes it is always a nop. It is designed such that address 0 can be used
as RAM in sandbox.

For PCI the mapping can in fact do something special, so that
memory-mapped peripherals can expose their registers. See
drivers/misc/swap_case.c for an example of that. But we have not ended
up with lots of tests.

>
> >
> >   pre_dot_num = fastboot_bytes_received / BYTES_PER_DOT;
> > @@ -296,13 +297,15 @@ void fastboot_data_complete(char *response)
> >   */
> >  static void __maybe_unused flash(char *cmd_parameter, char *response)
> >  {
> > + void *buf = map_sysmem(fastboot_buf_addr, 0);
> > +
> >   if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC))
> > - fastboot_mmc_flash_write(cmd_parameter, fastboot_buf_addr,
> > -  image_size, response);
> > + fastboot_mmc_flash_write(cmd_parameter, buf, image_size,
> > +  response);
> >
> >   if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND))
> > - fastboot_nand_flash_write(cmd_parameter, fastboot_buf_addr,
> > -   image_size, response);
> > + fastboot_nand_flash_write(cmd_parameter, buf, image_size,
> > +   response);
>
> Same here.
>
> >  }
> >

[..]

Regards,
Simon

Re: [PATCH v2 2/3] arm: dts: k3-*-binman: Move to using ti-dm entry type

[Simon Glass]

On Tue, 5 Dec 2023 at 02:42, Neha Malcom Francis  wrote:
>
> Move the DM entry in tispl.bin FIT image from default fetching an
> external blob entry to fetching using ti-dm entry type. This way, the
> DM entry will be populated by the TI_DM pathname if provided. Else it
> will resort to the ti-dm.bin file.
>
> Signed-off-by: Neha Malcom Francis 
> Reviewed-by: Andrew Davis 
> ---
>  arch/arm/dts/k3-am625-sk-binman.dtsi  | 4 ++--
>  arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++--
>  arch/arm/dts/k3-am62a-sk-binman.dtsi  | 4 ++--
>  arch/arm/dts/k3-j7200-binman.dtsi | 4 ++--
>  arch/arm/dts/k3-j721e-binman.dtsi | 4 ++--
>  arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++--
>  6 files changed, 12 insertions(+), 12 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v6 2/9] button: qcom-pmic: introduce Qualcomm PMIC button driver

[Simon Glass]

On Tue, 5 Dec 2023 at 06:47, Caleb Connolly  wrote:
>
> Qualcomm PMICs include a "pon" function which handles two buttons, the
> power button and "resin" button (usually volume down). Introduce a new
> driver following upstream Linux DT to enable these and map them to Enter
> and Down respectively to enable use in boot menus.
>
> Reviewed-by: Neil Armstrong 
> Reviewed-by: Sumit Garg 
> Tested-by: Sumit Garg 
> Signed-off-by: Caleb Connolly 
> ---
>  MAINTAINERS   |   1 +
>  drivers/button/Kconfig|   9 +++
>  drivers/button/Makefile   |   1 +
>  drivers/button/button-qcom-pmic.c | 165 
> ++
>  4 files changed, 176 insertions(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH v6 1/9] gpio: qcom_pmic: fix silent dev_read_addr downcast

[Simon Glass]

On Tue, 5 Dec 2023 at 06:47, Caleb Connolly  wrote:
>
> priv->pid is uint32_t, but dev_read_addr() returns a uint64_t on arm64,
> with the upper bits being used for error codes. Do error checking before
> downcasting to u32 to prevent errors being silently ignored.
>
> Reviewed-by: Sumit Garg 
> Reviewed-by: Neil Armstrong 
> Tested-by: Sumit Garg 
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/gpio/qcom_pmic_gpio.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v2 1/3] binman: etype: dm: Add entry type for TI DM

[Simon Glass]

On Tue, 5 Dec 2023 at 02:42, Neha Malcom Francis  wrote:
>
> K3 devices introduces the concept of centralized power, resource and
> security management to System Firmware. This is to overcome challenges
> by the traditional approach that implements system control functions on
> each of the processing units.
>
> The software interface for System Firmware is split into TIFS and DM. DM
> (Device Manager) is responsible for resource and power management from
> secure and non-secure hosts. This additional binary is necessary for
> specific platforms' ROM boot images and is to be packaged into tispl.bin
>
> Add an entry for DM. The entry can be used for the packaging of
> tispl.bin by binman along with ATF and TEE.
>
> Signed-off-by: Neha Malcom Francis 
> Reviewed-by: Andrew Davis 
> ---
>  Makefile|  1 +
>  tools/binman/entries.rst| 14 ++
>  tools/binman/etype/ti_dm.py | 22 ++
>  tools/binman/ftest.py   |  7 +++
>  tools/binman/test/225_ti_dm.dts | 13 +
>  5 files changed, 57 insertions(+)
>  create mode 100644 tools/binman/etype/ti_dm.py
>  create mode 100644 tools/binman/test/225_ti_dm.dts
>

Reviewed-by: Simon Glass 

Is there a doc/ update somewhere about TI_DM ?

Regards,
Simon

Re: [PATCH v6 6/9] dts: qcom: adjust pmic gpio to use upstream bindings

[Simon Glass]

Hi Caleb,

On Tue, 5 Dec 2023 at 06:48, Caleb Connolly  wrote:
>
> Use the upstream gpio-ranges property instead of gpio-count, and drop
> the bank-name property for Qualcomm boards.
>
> Reviewed-by: Neil Armstrong 
> Reviewed-by: Sumit Garg 
> Tested-by: Sumit Garg 
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/dragonboard410c.dts | 3 +--
>  arch/arm/dts/dragonboard820c.dts | 3 +--
>  arch/arm/dts/qcs404-evb.dts  | 3 +--
>  arch/arm/dts/sdm845.dtsi | 3 +--
>  4 files changed, 4 insertions(+), 8 deletions(-)
>

What is the replacement for the GPIO bank name?

Regards,
Simon

Re: [PATCH v6 5/9] gpio: qcom_pmic: support upstream DT

[Simon Glass]

On Tue, 5 Dec 2023 at 06:48, Caleb Connolly  wrote:
>
> Upstream uses the gpio-ranges property to define the number of GPIOs,
> support for parsing this when gpio-count is unspecified
>
> Additionally, drop the bank-name property as it isn't used in upstream,
> and we can just hardcode the bank name instead.
>
> Reviewed-by: Sumit Garg 
> Tested-by: Sumit Garg 
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/gpio/qcom_pmic_gpio.c | 31 ---
>  1 file changed, 28 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 01/18] bootm: netbds: Drop passing of arguments

[Simon Glass]

Hi,

I am replying to this email since it still has the context below.

On Mon, 4 Dec 2023 at 03:48, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Sun,  3 Dec 2023 17:26:17 -0700
>
> Hi Simon,
>
> There is a typo in first line of the commit message: s/netbds/netbsd/.
>
> > It isn't clear how useful it is to pass the arguments of bootm to the
> > OS. For example, if "bootm 1000 2000 3000" is used, the three arguments
> > at the end are passed to the OS. This seems like a strange approach,
> > since the argument have already been parsed by U-Boot and processed.
> >
> > Rely instead on the "bootargs" mechanism, which is the standard
> > approach.
>
> It is a very Linuxy approach though.
>
> I suspect this feature was added to pass kernel arguments for
> "one-off" boots.  For example
>
> bootm -s

Martin says that this is used with NetBSD. So do we rely on U-Boot
parsing the '-s' as 0 and then using loadaddr as the default?

I wonder if we could come up with another mechanism? Perhaps 'bootm --
args go here' ? Or define that if the first arg starts with '-' then
the args are not parsed?

Martin, would it be possible to send a patch to doc/ describing how to
boot NetBSD?


>
> could be used to boot NetBSD in single-user mode and is quite a bit
> more convenient than:
>
> setenv bootargs -s
> bootm
>
> That said, I'm not sure to what extent the bootm command is used to
> boot NetBSD these days.  So this may not really matter.
>
> Cheers,
>
> Mark
>
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  boot/bootm_os.c | 16 +++-
> >  1 file changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/boot/bootm_os.c b/boot/bootm_os.c
> > index b92422171a84..b5055d78706c 100644
> > --- a/boot/bootm_os.c
> > +++ b/boot/bootm_os.c
> > @@ -102,19 +102,9 @@ static int do_bootm_netbsd(int flag, int argc, char 
> > *const argv[],
> >   os_hdr = hdr;
> >   }
> >
> > - if (argc > 0) {
> > - ulong len;
> > - int   i;
> > -
> > - for (i = 0, len = 0; i < argc; i += 1)
> > - len += strlen(argv[i]) + 1;
> > - cmdline = malloc(len);
> > - copy_args(cmdline, argc, argv, ' ');
> > - } else {
> > - cmdline = env_get("bootargs");
> > - if (cmdline == NULL)
> > - cmdline = "";
> > - }
> > + cmdline = env_get("bootargs");
> > + if (!cmdline)
> > + cmdline = "";
> >
> >   loader = (void (*)(struct bd_info *, struct legacy_img_hdr *, char *, 
> > char *))images->ep;
> >
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >
> >

Re: [PATCH 00/21] Qualcomm generic board support

[Simon Glass]

Hi Sumit,

On Tue, 5 Dec 2023 at 00:44, Sumit Garg  wrote:
>
> Hi Simon,
>
> On Tue, 5 Dec 2023 at 06:22, Simon Glass  wrote:
> >
> > Hi Sumit,
> >
> > On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
> > >
> > > Hi Caleb,
> > >
> > > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  
> > > wrote:
> > > >
> > > > Historically, Qualcomm boards in U-Boot have all had their own
> > > > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > > > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > > > devicetree with little/no compatibility with upstream DT.
> > > >
> > > > This series makes a few final prepatory changes, and then replaces
> > > > almost all of the board specific code with generic alternatives. The end
> > > > result is that all Qualcomm boards both current and future (with the
> > > > exception of the db410c and db820c) can be supported by a single U-Boot
> > > > binary by just providing the correct DT. New boards can be added without
> > > > introducing any addition mach/ or board/ code or config options.
> > > >
> > > > Due to the nature of this change, the patch ("mach-snapdragon:
> > > > generalise board support") has become pretty big, I tried a few
> > > > different ways to represent this in git history, but the other methods
> > > > (e.g. adding a stub "generic" target and removing it again) were more
> > > > confusing and made for much messier git history. The current patch is
> > > > mostly atomic, but requires regenerating the config.
> > > >
> > > > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > > > this is dropped in favour of a adding a new vbus-supply property to the
> > > > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > > > future patch. This handles the common case of a board requiring some
> > > > regulator be enabled for USB host mode.
> > > >
> > >
> > > Thanks for your work. It is a good step towards a generalized u-boot
> > > on Qcom platforms. Although I would like to give it an in-depth
> > > review, I have a common discussion point about DT, see below.
> > >
> > > > A more detailed description of the changes is below.
> > > >
> > > > == Memory map ==
> > > >
> > > > The memory map was historically hardcoded into U-Boot, this meant that
> > > > U-Boot had to be built for a specific variant of a device. This is
> > > > changed to instead read the memory map from the DT /memory node.
> > > >
> > > > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > > > null pointer access happens then it will cause a bus stall (and board
> > > > hang). This is fixed so that null pointer accesses will now correctly
> > > > throw an exception.
> > > >
> > > > == DT loading ==
> > > >
> > > > Previously, boards used the FDT blob embedded into U-Boot (via
> > > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > > > bootloader, so we can instead rely on the first-stage bootloader to
> > > > populate some useful FDT properties for us (notably the /memory node and
> > > > KASLR seed) and fetch the DTB that it provides. Combined with the memory
> > > > map changes above, this let's us entirely avoid configuring the memory
> > > > map explicitly.
> > >
> > > Since with this change, we don't need to embed FDT blob in the u-boot
> > > binary, so I was thinking if we really need to import DTs from Linux
> > > for different platforms and then play a catchup game?
> > >
> > > IMO, the build command would look like following if we import
> > > pre-built FDT blob from Linux:
> > >
> > > - Build u-boot::
> > >
> > >$ export CROSS_COMPILE=
> > >$ make qcom_defconfig
> > >$ make
> > >
> > > - gzip u-boot::
> > >
> > >gzip u-boot-nodtb.bin
> > >
> > > - Append dtb to gzipped u-boot::
> > >
> > > cat u-boot-nodtb.bin.gz
> > > /arch/arm64/boot/dts/qcom/your-board.dtb >
> > > u-boot-nodtb.bin.gz-dtb
> >
> > What is this?? Who or what uses a gzipped image with a single DT attached?
>
> The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
> LK). It is the usual way Linux is booted on these platforms. U-boot is
> being brought into this chain to leverage standardized EFI boot
> processes.

LK is Little kernel, I believe. That is an open source project, right?
But I suppose it is BSD licensed so in fact the code is not available?
Is ABL obsolete?

I'm not sure that it matters in any case. We should be able to
standardise the U-Boot part and let the private projects implement
that, for a seamless boot.

What you have written above is not a good way for U-Boot to be
packaged or invoked.

>
> >
> > >
> > > This would avoid the maintenance burden to keep DT in sync with that
> > > of Linux. And since DT bindings in Linux are backwards compatible, we
> > > can say u-boot should work with DTB picked up from any Linux kernel
> > > stable release.
> >
> > That is not the current situation, unfortunately.
> >
>
> Hopefully with 

Re: [PATCH 00/21] Qualcomm generic board support

[Simon Glass]

Hi Caleb,

On Tue, 5 Dec 2023 at 03:55, Caleb Connolly  wrote:
>
>
>
> On 05/12/2023 07:44, Sumit Garg wrote:
> > Hi Simon,
> >
> > On Tue, 5 Dec 2023 at 06:22, Simon Glass  wrote:
> >>
> >> Hi Sumit,
> >>
> >> On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
> >>>
> >>> Hi Caleb,
> >>>
> >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  
> >>> wrote:
> [...]
>  == DT loading ==
> 
>  Previously, boards used the FDT blob embedded into U-Boot (via
>  OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
>  bootloader, so we can instead rely on the first-stage bootloader to
>  populate some useful FDT properties for us (notably the /memory node and
>  KASLR seed) and fetch the DTB that it provides. Combined with the memory
>  map changes above, this let's us entirely avoid configuring the memory
>  map explicitly.
> >>>
> >>> Since with this change, we don't need to embed FDT blob in the u-boot
> >>> binary, so I was thinking if we really need to import DTs from Linux
> >>> for different platforms and then play a catchup game?
> >>>
> >>> IMO, the build command would look like following if we import
> >>> pre-built FDT blob from Linux:
> >>>
> >>> - Build u-boot::
> >>>
> >>>$ export CROSS_COMPILE=
> >>>$ make qcom_defconfig
> >>>$ make
> >>>
> >>> - gzip u-boot::
> >>>
> >>>gzip u-boot-nodtb.bin
> >>>
> >>> - Append dtb to gzipped u-boot::
> >>>
> >>> cat u-boot-nodtb.bin.gz
> >>> /arch/arm64/boot/dts/qcom/your-board.dtb >
> >>> u-boot-nodtb.bin.gz-dtb
> >>
> >> What is this?? Who or what uses a gzipped image with a single DT attached?
> >
> > The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
> > LK). It is the usual way Linux is booted on these platforms. U-boot is
> > being brought into this chain to leverage standardized EFI boot
> > processes.
>
> Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm
> boards/devices are in right now (with the exception of db410c), with
> production devices we can't modify the bootloader without vendors
> releasing their signing keys.

Or perhaps a shim? It would be good if vendors could provide an unlock
mechanism eventually, but I understand it is challenging.

>
> For devices that haven't been locked with vendor keys ("Secureboot off"
> in Qualcomm terminology, note that this has nothing to do with UEFI
> secureboot) we can work towards replacing the bootloader entirely with
> U-Boot, I have done a PoC of this on SDM845. In that case, we have to
> embed the DTB into U-Boot.

OK, I see, that sounds good. My concern is that the open source
approach is preserved and made the easiest option. Decisions which
accommodate private binaries while making open source harder should
generally be rejected.

> >
> >>
> >>>
> >>> This would avoid the maintenance burden to keep DT in sync with that
> >>> of Linux. And since DT bindings in Linux are backwards compatible, we
> >>> can say u-boot should work with DTB picked up from any Linux kernel
> >>> stable release.
> >>
> >> That is not the current situation, unfortunately.
> >>
> >
> > Hopefully with efforts from Caleb and team we can reach that point soon.
> >
> >> U-Boot is moving to using Binman to package the firmware. There needs
> >> to be a description of the firmware image for each U-Boot boot. To my
> >> way of thinking, rpi is a degenerate form, not something to be copied,
> >> due to the closed-source nature of the firmware and its inability to
> >> be changed. We do have (in the works) a way to pass a DT using a
> >> standard firmware handoff. Perhaps that can be adopted by these
> >> closed-source projects?
> >
> > Why should we really need firmware handoff if the DT can be passed in
> > one of the u-boot boot arguments? Linux kernel does support this
> > method to retrieve DT as well.
>
> Unfortunately the chances of Qualcomm releasing bootloader updates to
> adopt a standard for chainloading U-Boot on their wholely deprecated
> platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no
> reason to care, and may not even be around anymore) apply these patches
> to their own hacked up fork of the bootloader and ship it to end-users
> is honestly even less likely than OEMs releasing the signing keys for
> devices they don't support anymore.

Yes, I understand it is challenging. Somehow it works better with
Linux, despite hacked up kernels, etc. so perhaps Linaro can help
here?

Regards,
Simon

[PATCH 1/2] clk: Check that composite clock's div has set_rate()

[Igor Prusov]

It's possible for composite clocks to have a divider that does not
implement set_rate() operation. For example, sandbox_clk_composite()
registers composite clock with a divider that only has get_rate().
Currently clk_composite_set_rate() only checks thate rate_ops are
present, so for sandbox it will cause NULL dereference during
clk_set_rate().

This patch adds rate_ops->set_rate check tp clk_composite_set_rate().

Signed-off-by: Igor Prusov 
---

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

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 6eb2b8133a..d2e5a1ae40 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -66,7 +66,7 @@ static ulong clk_composite_set_rate(struct clk *clk, unsigned 
long rate)
const struct clk_ops *rate_ops = composite->rate_ops;
struct clk *clk_rate = composite->rate;
 
-   if (rate && rate_ops)
+   if (rate && rate_ops && rate_ops->set_rate)
return rate_ops->set_rate(clk_rate, rate);
else
return clk_get_rate(clk);
-- 
2.34.1

[PATCH 2/2] dm: test: clk: Add test for ccf clk_set_rate()

[Igor Prusov]

Add a simple test case which sets clock rate to its current value.

Signed-off-by: Igor Prusov 
---

 test/dm/clk_ccf.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/test/dm/clk_ccf.c b/test/dm/clk_ccf.c
index e4ebb93cda..3b23982541 100644
--- a/test/dm/clk_ccf.c
+++ b/test/dm/clk_ccf.c
@@ -63,6 +63,9 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
rate = clk_get_parent_rate(clk);
ut_asserteq(rate, 6000);
 
+   rate = clk_set_rate(clk, 6000);
+   ut_asserteq(rate, -ENOSYS);
+
rate = clk_get_rate(clk);
ut_asserteq(rate, 6000);
 
@@ -87,6 +90,9 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
ut_asserteq_str("pll3_80m", pclk->dev->name);
ut_asserteq(CLK_SET_RATE_PARENT, pclk->flags);
 
+   rate = clk_set_rate(clk, 8000);
+   ut_asserteq(rate, -ENOSYS);
+
rate = clk_get_rate(clk);
ut_asserteq(rate, 8000);
 
@@ -108,6 +114,9 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
rate = clk_get_rate(clk);
ut_asserteq(rate, 6000);
 
+   rate = clk_set_rate(clk, 6000);
+   ut_asserteq(rate, 6000);
+
 #if CONFIG_IS_ENABLED(CLK_CCF)
/* Test clk tree enable/disable */
ret = clk_get_by_id(SANDBOX_CLK_I2C_ROOT, );
-- 
2.34.1

[PATCH 0/2] Fix NULL dereference in clk_composite_set_rate()

[Igor Prusov]

On sandbox it's possible to trigger NULL dereference when setting rate
of a composite clock. It happens because sandbox composite divider does
not implement set_rate() operation. This series adds NULL check and a
test cases for clk_set_rate().


Igor Prusov (2):
  clk: Check that composite clock's div has set_rate()
  dm: test: clk: Add test for ccf clk_set_rate()

 drivers/clk/clk-composite.c | 2 +-
 test/dm/clk_ccf.c   | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
2.34.1

Re: [PATCH] board: rockchip: add Powkiddy X55

[Jonas Karlman]

Hi Chris,

On 2023-12-05 22:39, Chris Morgan wrote:
> From: Chris Morgan 
> 
> The Powkiddy X55 is a Rockchip RK3566 based handheld gaming device.
> UART, ADC, eMMC, and SDMMC are tested to work.
> 
> Signed-off-by: Chris Morgan 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi |  67 ++
>  arch/arm/dts/rk3566-powkiddy-x55.dts | 926 +++
>  arch/arm/mach-rockchip/rk3568/Kconfig|   6 +
>  board/powkiddy/x55/Kconfig   |  15 +
>  board/powkiddy/x55/MAINTAINERS   |   8 +
>  board/powkiddy/x55/Makefile  |   6 +
>  board/powkiddy/x55/x55.c | 101 ++
>  configs/powkiddy-x55-rk3566_defconfig|  86 ++
>  doc/board/index.rst  |   1 +
>  doc/board/powkiddy/index.rst |   9 +
>  doc/board/powkiddy/x55.rst   |  46 +
>  include/configs/powkiddy-x55-rk3566.h|  12 +
>  13 files changed, 1284 insertions(+)
>  create mode 100644 arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3566-powkiddy-x55.dts
>  create mode 100644 board/powkiddy/x55/Kconfig
>  create mode 100644 board/powkiddy/x55/MAINTAINERS
>  create mode 100644 board/powkiddy/x55/Makefile
>  create mode 100644 board/powkiddy/x55/x55.c
>  create mode 100644 configs/powkiddy-x55-rk3566_defconfig
>  create mode 100644 doc/board/powkiddy/index.rst
>  create mode 100644 doc/board/powkiddy/x55.rst
>  create mode 100644 include/configs/powkiddy-x55-rk3566.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 1be08c5fdc..9e38bab6eb 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
>   rk3566-anbernic-rgxx3.dtb \
>   rk3566-quartz64-a.dtb \
>   rk3566-quartz64-b.dtb \
> + rk3566-powkiddy-x55.dtb \
>   rk3566-radxa-cm3-io.dtb \
>   rk3566-soquartz-blade.dtb \
>   rk3566-soquartz-cm4.dtb \
> diff --git a/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi 
> b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
> new file mode 100644
> index 00..2e3998a65a
> --- /dev/null
> +++ b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = 
> + u-boot,spl-boot-order = "same-as-spl", , 

This matches what is set in rk356x-u-boot.dtsi and can be droped.

> + };
> +
> + rng: rng@fe388000 {
> + compatible = "rockchip,cryptov2-rng";
> + reg = <0x0 0xfe388000 0x0 0x2000>;
> + status = "okay";
> + };
> +};
> +
> + {
> + assigned-clocks =
> + < CLK_RTC_32K>, < PLL_PPLL>,
> + < PCLK_PMU>, < PLL_CPLL>,
> + < PLL_GPLL>, < PLL_VPLL>,
> + < ACLK_BUS>, < PCLK_BUS>,
> + < ACLK_TOP_HIGH>, < ACLK_TOP_LOW>,
> + < HCLK_TOP>, < PCLK_TOP>,
> + < ACLK_PERIMID>, < HCLK_PERIMID>,
> + < CPLL_500M>, < CPLL_333M>,
> + < CPLL_250M>, < CPLL_125M>,
> + < CPLL_100M>, < CPLL_62P5M>,
> + < CPLL_50M>, < CPLL_25M>;
> + assigned-clock-rates =
> + <32768>, <2>,
> + <1>, <10>,
> + <12>, <12640>,
> + <15000>, <1>,
> + <5>, <4>,
> + <15000>, <1>,
> + <3>, <15000>,
> + <5>, <3>,
> + <25000>, <12500>,
> + <1>, <6250>,
> + <5000>, <2500>;
> + assigned-clock-parents =
> + < CLK_RTC32K_FRAC>;
> +};
> +
> + {
> + assigned-clocks = < SCLK_32K_IOE>;
> + assigned-clock-parents = < CLK_RTC_32K>;
> +};
> +
> +/*
> + * We don't need the clocks, but if they are present they may cause
> + * probing to fail so we remove them for U-Boot.
> + */
> + {
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ clocks;
> + /delete-property/ clock-names;
> +};

You should not need to remove these clock properties, the clk driver has
dummy support for the referenced I2S1_MCLKOUT_TX clock.

> +
> + {
> + clock-frequency = <2400>;
> + bootph-all;
> + status = "okay";
> +};

[...]

> diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig 
> b/arch/arm/mach-rockchip/rk3568/Kconfig
> index baa51349f4..a97da8ae55 100644
> --- a/arch/arm/mach-rockchip/rk3568/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3568/Kconfig
> @@ -22,6 +22,11 @@ config TARGET_ODROID_M1_RK3568
>   help
>   

[PATCH] board: rockchip: add Powkiddy X55

[Chris Morgan]

From: Chris Morgan 

The Powkiddy X55 is a Rockchip RK3566 based handheld gaming device.
UART, ADC, eMMC, and SDMMC are tested to work.

Signed-off-by: Chris Morgan 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi |  67 ++
 arch/arm/dts/rk3566-powkiddy-x55.dts | 926 +++
 arch/arm/mach-rockchip/rk3568/Kconfig|   6 +
 board/powkiddy/x55/Kconfig   |  15 +
 board/powkiddy/x55/MAINTAINERS   |   8 +
 board/powkiddy/x55/Makefile  |   6 +
 board/powkiddy/x55/x55.c | 101 ++
 configs/powkiddy-x55-rk3566_defconfig|  86 ++
 doc/board/index.rst  |   1 +
 doc/board/powkiddy/index.rst |   9 +
 doc/board/powkiddy/x55.rst   |  46 +
 include/configs/powkiddy-x55-rk3566.h|  12 +
 13 files changed, 1284 insertions(+)
 create mode 100644 arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3566-powkiddy-x55.dts
 create mode 100644 board/powkiddy/x55/Kconfig
 create mode 100644 board/powkiddy/x55/MAINTAINERS
 create mode 100644 board/powkiddy/x55/Makefile
 create mode 100644 board/powkiddy/x55/x55.c
 create mode 100644 configs/powkiddy-x55-rk3566_defconfig
 create mode 100644 doc/board/powkiddy/index.rst
 create mode 100644 doc/board/powkiddy/x55.rst
 create mode 100644 include/configs/powkiddy-x55-rk3566.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc..9e38bab6eb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-quartz64-a.dtb \
rk3566-quartz64-b.dtb \
+   rk3566-powkiddy-x55.dtb \
rk3566-radxa-cm3-io.dtb \
rk3566-soquartz-blade.dtb \
rk3566-soquartz-cm4.dtb \
diff --git a/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi 
b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
new file mode 100644
index 00..2e3998a65a
--- /dev/null
+++ b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+
+   rng: rng@fe388000 {
+   compatible = "rockchip,cryptov2-rng";
+   reg = <0x0 0xfe388000 0x0 0x2000>;
+   status = "okay";
+   };
+};
+
+ {
+   assigned-clocks =
+   < CLK_RTC_32K>, < PLL_PPLL>,
+   < PCLK_PMU>, < PLL_CPLL>,
+   < PLL_GPLL>, < PLL_VPLL>,
+   < ACLK_BUS>, < PCLK_BUS>,
+   < ACLK_TOP_HIGH>, < ACLK_TOP_LOW>,
+   < HCLK_TOP>, < PCLK_TOP>,
+   < ACLK_PERIMID>, < HCLK_PERIMID>,
+   < CPLL_500M>, < CPLL_333M>,
+   < CPLL_250M>, < CPLL_125M>,
+   < CPLL_100M>, < CPLL_62P5M>,
+   < CPLL_50M>, < CPLL_25M>;
+   assigned-clock-rates =
+   <32768>, <2>,
+   <1>, <10>,
+   <12>, <12640>,
+   <15000>, <1>,
+   <5>, <4>,
+   <15000>, <1>,
+   <3>, <15000>,
+   <5>, <3>,
+   <25000>, <12500>,
+   <1>, <6250>,
+   <5000>, <2500>;
+   assigned-clock-parents =
+   < CLK_RTC32K_FRAC>;
+};
+
+ {
+   assigned-clocks = < SCLK_32K_IOE>;
+   assigned-clock-parents = < CLK_RTC_32K>;
+};
+
+/*
+ * We don't need the clocks, but if they are present they may cause
+ * probing to fail so we remove them for U-Boot.
+ */
+ {
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ clocks;
+   /delete-property/ clock-names;
+};
+
+ {
+   clock-frequency = <2400>;
+   bootph-all;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3566-powkiddy-x55.dts 
b/arch/arm/dts/rk3566-powkiddy-x55.dts
new file mode 100644
index 00..4786b19fd0
--- /dev/null
+++ b/arch/arm/dts/rk3566-powkiddy-x55.dts
@@ -0,0 +1,926 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   model = "Powkiddy x55";
+   compatible = "powkiddy,x55", "rockchip,rk3566";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   mmc2 = 
+   mmc3 = 
+   };
+
+   chosen: chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc_joystick: 

Re: [PATCH v2 0/3] rpi5: initial support

[Peter Robinson]

Hi Dmitry,

> First of all, thank you for all your reviews. I hope I can answer all
> your questions here. If I forget something please let me know.

Absolutely.

> I don't have much experience with arm/arm64 and I don't have previous
> experience with u-boot and contributing to it. So please guide me for
> next steps.

I think you're doing fine, generally the process is wait for some
review, incorporate the feedback into patches and after a little while
send a new rev.

> Also I don't think it makes sense to expect all devices or any device
> may/should work after initial boot support. I would suggest going with
> small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> after initial support is being merged.

I agree with that point mostly, and that is my intention, from my PoV
it was more me replying to the comments you had made about outsanding
issues and what my thoughts were to address them.

That being said I think we need two things to be able to land this
upstream 1) working output such as serial console (this is ticket) 2)
working storage so it can load things like the Linux kernel off disk
and boot, the shortest path to this is likely MMC. Everything else
(gfx/net/usb etc) can be added later in incremental patches. I
apologies if my reply didn't come across at that, it was as much
documented my discoveries for everyone else on the list following
along.

> > Could this be the title for the patch, "initial support" is fine for
> > the cover letter, but doesn't really out line what this specific patch
> > actually does.
> Can confirm. My bad. Will fix it in the next patchset.
>
> >> includes:
> >> * 1GB of RAM (from 4GB or 8GB total)
> >> * VPU memory interface
> >> * SOC range (main peripherals)
>
> > Could you include details where this information came from as well please?
> By looking into FDT for memory, framebuffer, and soc nodes. I can add
> this info in v3.
>
>
> > When you say it doesn't work, does it just not output display or does
> > the device lock up and you need to disable it?
> There are artifacts on the screen and the system locks up.

OK, good to know, we can't really disable display ATM as it'll regress
other rpi devices supported in this config.

>
> > For the rpi4 it was as simple as adding a new compatible [1] for the
> > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > updating registers [2] so I'm not sure if we're going to need to do
> > more for this or not.
> I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> And no luck. Still visible artifacts on the screen. I see valid debug
> output from bcm2835_video_probe() so the mailbox for set/get
> base/resolution/pitch/stride works. But still observe the same issue
> with artifacts and lock up. FYI by default the probing starts due to
> "bcm2708-fb".
>
>
> > Might be worth looking to see if there's changes in the kernel for
> > this. In an initial look I didn't see any changes to their kernel
> > here.
> I don't see any changes either. I'm not able to find any official
> confirmation. But most of 'tags' work except two or three. And all of
> them have response code 0x8000_0001. And FDT contains new info
> compared to old versions (for these tags). Which leads to the
> conclusion they are deprecated.
>
>
> > We probably need a patch to the identifier too similar to the following:
> > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> Honestly I didn't get the reason/goal besides old/new scheme except
> there is a final print:
> > printf("RPI %s (0x%x)\n", model->name, revision);
> which is kind of simular to my:
> > printf("FW FDT model : %s\n", fdt_model);

The main reason for the detection is if there needs to be a kernel DT
loaded off disk, it's a more definitive way of detecting the HW rev
because the fdt model could be repeated across different revs of the
same variant.

> Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> revision from it? Format is unknown and nobody knows what will be
> changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> suggest parsing OTP to get precise info with known format.

Hence the reason to use the official hex identifiers.

> P.S.: Please let me know if I answered all the questions so I can send v3.

I think so. The outstanding things we will need to resolve to land
this, other than the polish I've outlined in various replies, is:
1) working storage to load an OS
2) not disabling the display driver and not have it crash. The display
on the rpi5 doesn't need to work, we just don't want to regress
existing users.

This won't be landing in 2024.01 now so we have time to get this
ready. I'll start to play in the coming days.

Peter

Re: [PATCH v2 0/3] rpi5: initial support

[Peter Robinson]

Hi Dmitry,

> > I've given these a cursory look over, I have a system to test and will
> > give them a whirl in the next few days, I was planning to start
> > playing over the weekend so you've provided a great start :)
>
> Did you have any chance to test my patches?

Not yet, apologies, work has been a bit intense over the last couple
of weeks so I've not had many cycles in the free time I use for RPi
outside of work to do this. I do have the RPi5 up and running now
though so I can start to test.

I was going to reply to your last reply, I will do that in a moment.

Peter

> > Hi guys,
> >
> > First of all, thank you for all your reviews. I hope I can answer all
> > your questions here. If I forget something please let me know.
> >
> > I don't have much experience with arm/arm64 and I don't have previous
> > experience with u-boot and contributing to it. So please guide me for
> > next steps.
> >
> > Also I don't think it makes sense to expect all devices or any device
> > may/should work after initial boot support. I would suggest going with
> > small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> > after initial support is being merged.
> >
> > > Could this be the title for the patch, "initial support" is fine for
> > > the cover letter, but doesn't really out line what this specific patch
> > > actually does.
> > Can confirm. My bad. Will fix it in the next patchset.
> >
> > >> includes:
> > >> * 1GB of RAM (from 4GB or 8GB total)
> > >> * VPU memory interface
> > >> * SOC range (main peripherals)
> >
> > > Could you include details where this information came from as well please?
> > By looking into FDT for memory, framebuffer, and soc nodes. I can add
> > this info in v3.
> >
> >
> > > When you say it doesn't work, does it just not output display or does
> > > the device lock up and you need to disable it?
> > There are artifacts on the screen and the system locks up.
> >
> >
> > > For the rpi4 it was as simple as adding a new compatible [1] for the
> > > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > > updating registers [2] so I'm not sure if we're going to need to do
> > > more for this or not.
> > I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> > And no luck. Still visible artifacts on the screen. I see valid debug
> > output from bcm2835_video_probe() so the mailbox for set/get
> > base/resolution/pitch/stride works. But still observe the same issue
> > with artifacts and lock up. FYI by default the probing starts due to
> > "bcm2708-fb".
> >
> >
> > > Might be worth looking to see if there's changes in the kernel for
> > > this. In an initial look I didn't see any changes to their kernel
> > > here.
> > I don't see any changes either. I'm not able to find any official
> > confirmation. But most of 'tags' work except two or three. And all of
> > them have response code 0x8000_0001. And FDT contains new info
> > compared to old versions (for these tags). Which leads to the
> > conclusion they are deprecated.
> >
> >
> > > We probably need a patch to the identifier too similar to the following:
> > > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> > Honestly I didn't get the reason/goal besides old/new scheme except
> > there is a final print:
> > > printf("RPI %s (0x%x)\n", model->name, revision);
> > which is kind of simular to my:
> > > printf("FW FDT model : %s\n", fdt_model);
> >
> > Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> > revision from it? Format is unknown and nobody knows what will be
> > changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> > 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> > suggest parsing OTP to get precise info with known format.
> >
> > P.S.: Please let me know if I answered all the questions so I can send v3.
> >
> > Regards,
> > Dmitry
>
> I haven't heard any updates. Should I send v3?

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

On Wed, 6 Dec 2023 at 00:25, Soeren Moch  wrote:

>
>
> On 05.12.23 17:25, Maxim Uvarov wrote:
>
>
>
> On Tue, 5 Dec 2023 at 21:49, Soeren Moch  wrote:
>
>> On 05.12.23 14:15, Maxim Uvarov wrote:
>>
>> I think I solved the size issue on all the boards.
>>
>> Key changes:
>> 1. remove compilation of original ping.c and tftp.c (tftp had also server
>> code, so I will partially bring it back.)
>>
>> Interesting.
>> @Tom: Is there other server code in u-boot, that is enabled by default
>> (and can be used to reclaim code space)?
>> Fur sure I do not need u-boot to act as server for tftp (maye nfs,
>> others).
>>
>
> Maybe I need to be more clear about this. reference to code from tftp.c
> and ping.c exist in net.c, test/image/spl_load_net.c, test.dm/dsa.c,
> test/dm/eth.c.
> And even if that code is not used (replaced with lwip calls to the same
> commands in my case) it adds additional size. Even enabled LTO does not see
> direct difference.
>
> So 'server code' does not mean u-boot acting as network server, you mean
> this code is referenced by something else? And things in test do increase
> image size?
>
>
>
>
>> 2. LTO=y
>> 3. CONFIG_LOGLEVEL=3 instead of 4.
>> 4. CONFIG_CMD_DATE is not set
>> 5. CONFIG_CMD_LICENSE is not set
>> 6. CONFIG_CMD_PING (if 1-6 did not help).
>>
>> And these changes were enough for CI tagrets to build.
>> I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for
>> other boards to test.
>>
>> For example for this tbs2910 board changes are:
>>
>> Disabling CMD_DATE is unfortunate. This can help to debug RTC problems
>> (already used it for this purpose).
>> And, if we are that close to the size limit, than maybe we can get away
>> for this series, but for sure will run into trouble for every other small
>> change to u-boot core/driver code.
>>
>> Regards,
>> Soeren
>>
>
> The problem is that for many targets the limit is 1MB.
>
> For tbs2910 it is 383kBytes. And there was plenty of free space when I
> introduced mainline u-boot support. But yes, space got tighter over time.
>

Hm,
orig:
-rw-r--r-- 1 uboot uboot 371K Dec  5 19:54 u-boot.bin
lwip:
-rw-r--r-- 1 uboot uboot 380K Dec  5 19:55 u-boot.bin

Then if I just enable CMD_DATE:
u-boot.imx exceeds file size limit:
  limit:  0x5fc00 bytes
  actual: 0x60c00 bytes
  excess: 0x1000 bytes
make: *** [Makefile:1240: u-boot.imx] Error 1
make: *** Deleting file 'u-boot.imx'
uboot@3eebd85985c8:~/uboot-size$ ls -lh u-boot.bin
-rw-r--r-- 1 uboot uboot 382K Dec  5 19:58 u-boot.bin

So limit for your board is:
(gdb) p 0x5fc00/1024
$1 = 383

383k. Where do you see the space?

BR,
Maxim.



> U-Boot in some minimal configuration is about 500kb. But U-boot with EFI,
> USB, Eth drivers,  MMC, RTC, and all the commands is 900+ kb and very close
> to 1MB. Most of the new features are enabled by default.
>
> No. Tom does a very good job to ensure that there is no (not much)
> additional space required for unrelated boards that do not need new
> features.
>
> I.e. they do not exist in _defconfig and appear in the resulting .config
> automatically.  I would say that for some small targets things like EFI,
> Secure boot, TPM, Updates and many others are not needed. But if new
> features will appear by default very soon we will see limits.
>
> New features will not be enabled for old space constrained boards. In your
> series you did not offer to keep the old implementation instead, this is
> different and the reason why we discuss image size constraints.
>
> Regards,
> Soeren
>
>
> BR,
> Maxim.
>
>>
>> --- a/configs/tbs2910_defconfig
>> +++ b/configs/tbs2910_defconfig
>> @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
>>  CONFIG_LTO=y
>>  CONFIG_HAS_BOARD_SIZE_LIMIT=y
>>  CONFIG_BOARD_SIZE_LIMIT=392192
>> +CONFIG_TIMESTAMP=y (this was added by savedefconfig)
>>  # CONFIG_BOOTSTD is not set
>>  CONFIG_SUPPORT_RAW_INITRD=y
>>  CONFIG_BOOTDELAY=3
>> @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1;
>> then run bootcmd_up2; else r
>>  CONFIG_USE_PREBOOT=y
>>  CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
>>  CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"
>> +CONFIG_LOGLEVEL=3
>>  CONFIG_PRE_CONSOLE_BUFFER=y
>>  CONFIG_HUSH_PARSER=y
>>  CONFIG_SYS_PROMPT="Matrix U-Boot> "
>> @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y
>>  CONFIG_CMD_MII=y
>>  CONFIG_CMD_PING=y
>>  CONFIG_CMD_CACHE=y
>> -CONFIG_CMD_TIME=y
>> +# CONFIG_CMD_DATE is not set
>>  CONFIG_CMD_SYSBOOT=y
>>  # CONFIG_CMD_VIDCONSOLE is not set
>>  CONFIG_CMD_EXT2=y
>>
>> BR,
>> Maxim.
>>
>>
>> On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov 
>> wrote:
>>
>>>
>>>
>>> On Tue, 28 Nov 2023 at 03:20, Soeren Moch  wrote:
>>>
 On 27.11.23 14:11, Tom Rini wrote:
 > On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov wrote:
 >
 >> Increase allowed binary size to fit lwip code.
 >>
 >> Signed-off-by: Maxim Uvarov 
 >> ---
 >>   configs/tbs2910_defconfig | 2 +-
 >>   1 file changed, 1 insertion(+), 1 deletion(-)
 >>
 >> diff --git 

Re: bootstd: Support for distro specific EFI folders

[Shantur Rathore]

Hi Simon and Heinrich,

On Sun, Dec 3, 2023 at 8:38 PM Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Sun, 3 Dec 2023 at 13:00, Heinrich Schuchardt
>  wrote:
> >
> > On 12/3/23 20:50, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Sun, 3 Dec 2023 at 11:33, Heinrich Schuchardt
> > >  wrote:
> > >>
> > >> On 12/3/23 19:22, Simon Glass wrote:
> > >>> Hi Heinrich,
> > >>>
> > >>> On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt
> > >>>  wrote:
> > 
> >  On 12/3/23 18:44, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt
> > >  wrote:
> > >>
> > >> On 12/3/23 00:38, Shantur Rathore wrote:
> > >>> Hi Simon,
> > >>>
> > >>> On Sat, Dec 2, 2023 at 6:33 PM Simon Glass  
> > >>> wrote:
> > 
> >  Hi,
> > 
> >  On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas
> >   wrote:
> > >
> > > Hi Mark,
> > >
> > > On Sun, 19 Nov 2023 at 19:38, Mark Kettenis 
> > >  wrote:
> > >>
> > >>> Date: Sat, 18 Nov 2023 23:52:11 +0100
> > >>> From: Heinrich Schuchardt 
> > >>
> > >> Hi Heinrich,
> > >>
> > >>> On 11/18/23 22:28, Shantur Rathore wrote:
> >  Hi Heinrich,
> > 
> >  On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt
> >   wrote:
> > >
> > > On 11/16/23 19:45, Shantur Rathore wrote:
> > >> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt
> > >>  wrote:
> > >>>
> > >>> On 11/16/23 17:52, Shantur Rathore wrote:
> >  Hi Simon,
> > 
> >  Currently bootstd - bootmethod_efi only looks for the 
> >  default
> >  bootxx64.efi in /EFI/boot folder only.
> >  Generally many distros end up putting their bootloaders in
> >  EFI/ folders like EFI/ubuntu and EFI/debian etc.
> > 
> >  In x86 worlds, the NVRAM is modified and new boot entries 
> >  are added to
> >  support these but in the U-boot world the NVRAM variables 
> >  are
> >  read-only.
> > >>>
> > >>> I guess you are referring to UEFI boot options. These 
> > >>> typically are not
> > >>> stored in non-volatile RAM but on a SPI flash device.
> > >>>
> > >>
> > >> Thanks for correcting me.
> > >>
> > 
> >  What would be the best way to implement this?
> > 
> >  I was thinking of having a "efi_prefixes" environment 
> >  variable which
> >  can be set to "ubuntu debian centos" etc and 
> >  bootmethod_efi can try
> >  all of them. Will bootmethod_efi be able to support 
> >  multiple entries (
> >  thinking of multiboot ) ?
> > >>>
> > >>> On my laptop I have:
> > >>>
> > >>> EFI/Microsoft/Boot/bootmgr.efi
> > >>> EFI/Microsoft/Boot/memtest.efi
> > >>> EFI/Boot/bootx64.efi
> > >>> EFI/Boot/fbx64.efi
> > >>> EFI/Boot/mmx64.efi
> > >>> EFI/debian/shimx64.efi
> > >>> EFI/debian/grubx64.efi
> > >>> EFI/debian/mmx64.efi
> > >>> EFI/debian/fbx64.efi
> > >>> EFI/ubuntu/grubx64.efi
> > >>> EFI/ubuntu/shimx64.efi
> > >>> EFI/ubuntu/mmx64.efi
> > >>>
> > >>> Obviously each installed operating system provides multiple 
> > >>> EFI binaries
> > >>> and non uses the fallback file name BOOT.EFI. A value 
> > >>> "ubuntu
> > >>> debian centos" would not be able to describe which file you 
> > >>> are looking
> > >>> for.
> > >>>
> > >>> We already have the U-Boot command line eficonfig and 
> > >>> efidebug commands
> > >>> to set up UEFI boot options which can describe which EFI 
> > >>> binary to load
> > >>> and which command line to pass to it. These are considered 
> > >>> by the
> > >>> existing boot flows.
> > >>
> > >> So, I am building a new RockPro64 based cluster and using 
> > >> Canonical
> > >> MAAS to set them up automatically, booting them up using 
> > >> DHCP and
> > >> installing them over the network.
> > >> I configured an Armbian image using Packer to be compatible 
> > >> with MAAS
> > >> and it happily installs it. As part of installation process, 
> > >> a
> > >> 

Re: [PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support

[Andre Przywara]

On Sun, 3 Dec 2023 21:57:51 -0800
Stephen Graf  wrote:

Hi Stephen,

> I have tested a newly built u-boot with the patches you provided and it works 
> well.
> It is the same configuration as what I have been testing with for the last 
> few weeks.
> 
> I loaded the U-boot to SPI flash and tested with the SD card removed from the 
> system
> and put in a USB card reader. The output for that test is below.

thanks for your testing efforts! Is it OK if I convert this statement into
a "Tested-by:" tag with your email, to become part of the commit?

Cheers,
Andre


> For completeness you might want to mention that another difference between 
> the zero2
> and zero3 is the emac phy going from Realtek to Motorcomm.
> 
> Thank you for fixing my patch attempt. It is the first one I have ever done.
> Thank you also for your patience with my fumbling attempts. I have learned a 
> lot
> from you in the last two weeks.
> 
> U-Boot SPL 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800)
> DRAM: 1024 MiB
> Trying to boot from sunxi SPI
> NOTICE:  BL31: v2.10.0  (debug):v2.10.0
> NOTICE:  BL31: Built : 18:07:18, Nov 23 2023
> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
> NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2828, model: OrangePi Zero3
> INFO:ARM GICv2 driver initialized
> INFO:Configuring SPC Controller
> INFO:PMIC: Probing AXP305 on RSB
> ERROR:   RSB: set run-time address: 0x10003
> INFO:Could not init RSB: -65539
> INFO:BL31: Platform setup done
> INFO:BL31: Initializing runtime services
> INFO:BL31: cortex_a53: CPU workaround for erratum 855873 was applied
> INFO:BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
> INFO:PSCI: Suspend is unavailable
> INFO:BL31: Preparing for EL3 exit to normal world
> INFO:Entry point address = 0x4a00
> INFO:SPSR = 0x3c9
> INFO:Changed devicetree.
> 
> 
> U-Boot 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) 
> Allwinner Technology
> 
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  1 GiB
> Core:  57 devices, 25 uclasses, devicetree: separate
> WDT:   Not starting watchdog@30090a0
> MMC:   mmc@402: 0
> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size 
> 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:serial@500
> Out:   serial@500
> Err:   serial@500
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@502using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether
> starting USB...
> Bus usb@520: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@520 for devices... Device NOT ready
> Request Sense returned 02 3A 00
> Device NOT ready
> Request Sense returned 02 3A 00
> Device NOT ready
> Request Sense returned 02 3A 00
> 2 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select! : -110
> 
> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
>  Type: Removable Hard Disk
>  Capacity: 15193.5 MB = 14.8 GB (31116288 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot/boot.scr
> 1052 bytes read in 1 ms (1 MiB/s)
> ## Executing script at 4fc0
> Card did not respond to voltage select! : -110
> ** Bad device specification mmc 0 **
> 19472 bytes read in 3 ms (6.2 MiB/s)
> No FDT memory address configured. Please configure
> the FDT address via "fdt addr " command.
> Aborting!
> 7088139 bytes read in 324 ms (20.9 MiB/s)
> 22491144 bytes read in 1025 ms (20.9 MiB/s)
> Moving Image from 0x4008 to 0x4020, end=4180
> ## Loading init Ramdisk from Legacy Image at 4ff0 ...
> Image Name:   uInitrd
> Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
> Data Size:7088075 Bytes = 6.8 MiB
> Load Address: 
> Entry Point:  
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa0
> Booting using the fdt blob at 0x4fa0
> Working FDT set to 4fa0
> Loading Ramdisk to 4993d000, end 49fff7cb ... OK
> Loading Device Tree to 49935000, end 4993cc0f ... OK
> Working FDT set to 49935000
> 
> Starting kernel ...
> 
> 
> Welcome to Debian GNU/Linux 12 (bookworm)!
> 
> 
> 
> On 2023-12-03 4:59 p.m., Andre Przywara wrote:
> > A small update for the OrangePi Zero 3 support series. This fixes
> > USB support, and upgrades the DRAM clock to 792, for better stability
> > (as the other DRAM parameters were tailored to that frequency). I added
> > the tags on the way.
> > Please test!
> > 
> > =
> > The OrangePi Zero 3 is a small development board featuring the Allwinner
> > H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses
> > LPDDR4 DRAM 

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Soeren Moch]

On 05.12.23 17:25, Maxim Uvarov wrote:



On Tue, 5 Dec 2023 at 21:49, Soeren Moch  wrote:

On 05.12.23 14:15, Maxim Uvarov wrote:

I think I solved the size issue on all the boards.

Key changes:
1. remove compilation of original ping.c and tftp.c (tftp had
also server code, so I will partially bring it back.)

Interesting.
@Tom: Is there other server code in u-boot, that is enabled by
default (and can be used to reclaim code space)?
Fur sure I do not need u-boot to act as server for tftp (maye nfs,
others).


Maybe I need to be more clear about this. reference to code from
tftp.c and ping.c exist in net.c, test/image/spl_load_net.c,
test.dm/dsa.c , test/dm/eth.c.
And even if that code is not used (replaced with lwip calls to the
same commands in my case) it adds additional size. Even enabled LTO
does not see
direct difference.

So 'server code' does not mean u-boot acting as network server, you mean
this code is referenced by something else? And things in test do
increase image size?



2. LTO=y
3. CONFIG_LOGLEVEL=3 instead of 4.
4. CONFIG_CMD_DATE is not set
5. CONFIG_CMD_LICENSE is not set
6. CONFIG_CMD_PING (if 1-6 did not help).

And these changes were enough for CI tagrets to build.
I also tested that Raspberry PI 4B works fine (dhcp, ping).
Looking for other boards to test.

For example for this tbs2910 board changes are:

Disabling CMD_DATE is unfortunate. This can help to debug RTC
problems (already used it for this purpose).
And, if we are that close to the size limit, than maybe we can get
away for this series, but for sure will run into trouble for every
other small change to u-boot core/driver code.

Regards,
Soeren


The problem is that for many targets the limit is 1MB.

For tbs2910 it is 383kBytes. And there was plenty of free space when I
introduced mainline u-boot support. But yes, space got tighter over time.

U-Boot in some minimal configuration is about 500kb. But U-boot with
EFI, USB, Eth drivers,  MMC, RTC, and all the commands is 900+ kb and
very close to 1MB. Most of the new features are enabled by default.

No. Tom does a very good job to ensure that there is no (not much)
additional space required for unrelated boards that do not need new
features.

I.e. they do not exist in _defconfig and appear in the resulting
.config automatically.  I would say that for some small targets things
like EFI, Secure boot, TPM, Updates and many others are not needed.
But if new features will appear by default very soon we will see limits.

New features will not be enabled for old space constrained boards. In
your series you did not offer to keep the old implementation instead,
this is different and the reason why we discuss image size constraints.

Regards,
Soeren


BR,
Maxim.



--- a/configs/tbs2910_defconfig
+++ b/configs/tbs2910_defconfig
@@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
 CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
 CONFIG_BOARD_SIZE_LIMIT=392192
+CONFIG_TIMESTAMP=y (this was added by savedefconfig)
 # CONFIG_BOOTSTD is not set
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOOTDELAY=3
@@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run
bootcmd_up1; then run bootcmd_up2; else r
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
 CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"
+CONFIG_LOGLEVEL=3
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Matrix U-Boot> "
@@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
-CONFIG_CMD_TIME=y
+# CONFIG_CMD_DATE is not set
 CONFIG_CMD_SYSBOOT=y
 # CONFIG_CMD_VIDCONSOLE is not set
 CONFIG_CMD_EXT2=y

BR,
Maxim.


On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov
 wrote:



On Tue, 28 Nov 2023 at 03:20, Soeren Moch  wrote:

On 27.11.23 14:11, Tom Rini wrote:
> On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov
wrote:
>
>> Increase allowed binary size to fit lwip code.
>>
>> Signed-off-by: Maxim Uvarov 
>> ---
>>   configs/tbs2910_defconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/tbs2910_defconfig
b/configs/tbs2910_defconfig
>> index 8fbe84f1d2..ce40efa9ab 100644
>> --- a/configs/tbs2910_defconfig
>> +++ b/configs/tbs2910_defconfig
>> @@ -17,7 +17,7 @@ CONFIG_SYS_MEMTEST_START=0x1000
>>   CONFIG_SYS_MEMTEST_END=0x2f40
>>   CONFIG_LTO=y
>>   CONFIG_HAS_BOARD_SIZE_LIMIT=y
>> -CONFIG_BOARD_SIZE_LIMIT=392192
>> +CONFIG_BOARD_SIZE_LIMIT=417792
>>   # CONFIG_BOOTSTD is not set
  

Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree

[Doug Anderson]

Hi,

On Tue, Dec 5, 2023 at 3:16 AM Ahmad Fatoum  wrote:
>
> Hello,
>
> On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37 AM Simon 
> Glass  wrote:
> >> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum  wrote:
> >>> On 30.11.23 21:30, Simon Glass wrote:
>  On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum  
>  wrote:
> > On 29.11.23 20:44, Simon Glass wrote:
>  I don't have an example to hand, but this is the required mechanism of
>  FIT. This feature has been in place for many years and is used by
>  ChromeOS, at least.
> >>>
> >>> I see the utility of a FIT configuration with
> >>>
> >>> compatible = "vendor,board-rev-a", "vendor,board-rev-b";
> >>>
> >>> I fail to see a utility for a configuration with
> >>>
> >>> compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
> >>>
> >>> Any configuration that ends up being booted because "vendor,SoC" was 
> >>> matched is
> >>> most likely doomed to fail. Therefore, I would suggest that only the top 
> >>> level
> >>> configuration is written into the FIT configurations automatically.
> >>
> >> Firstly, I am not an expert on this.
> >>
> >> Say you have a board with variants. The compatible string in U-Boot
> >> may be something like:
> >>
> >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >>
> >> If you then have several FIT configurations, they may be something like:
> >>
> >> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >>
> >> You want to choose the second one, since it is a better match than the 
> >> others.
>
> Now imagine, you are building a kernel that has no DT support for the Veyron,
> but instead has support for the Phytec RK3288 PCM-947:
>
>   phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288
>
> As far as I understand U-Boot code, A veyron U-Boot would boot the Phytec DT
> if CONFIG_FIT_BEST_MATCH is set, although it's a bad match and a boot failure
> should rather have occurred.

On depthcharge the bootloader never matches on just a SoC name.


> >> +Doug Anderson who knows a lot more about this than me.
> >
> > Hopefully this is all explained by:
> >
> > https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
>
> Thanks Doug, this was helpful. The missing information to me was that
> depthcharge only compares the top-level board compatible in addition
> to runtime generated board compatibles, unlike what U-Boot seems to do.
>
> barebox only compares its top-level compatible against the FIT configuration
> compatibles, so adding a full compatible list to the configuration nodes as 
> done
> by this series should be ok there as well. I think U-Boot could run into
> issues though as described above.
>
> Out of curiosity: I only heard about Depthcharge before as exploitation 
> toolkit
> for U-Boot. Can you point me at some documentation on what the Depthcharge 
> bootloader
> does what U-Boot (which was presumably used before?) doesn't?

I can only assume that the depthcharge you're talking about is
different. The one used by Chromebooks is basically:

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main

I assume you're asking: why are we using depthcharge in ChromeOS
instead of U-Boot?

There was much discussion about this back in the day. From what I
recall, part of the reason was that folks wanted the boot flow to be a
bit more standard between x86 Chromebooks and ARM Chromebooks. x86
Chromebooks were using coreboot for the initial hardware booting and
then needed a 2nd stage to actually load Linux and ended up creating
depthcharge. ...and then we switched to the same model for ARM boards.

I didn't personally make that decision and I'm also not on the
firmware team, so that's about all I'll say on the topic. ;-)

Oh, hmmm. Searching found me:

https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware/

...which pointed at:

https://www.chromium.org/chromium-os/2014-firmware-summit/ChromeOS%20firmware%20summit%20-%20Depthcharge.pdf

-Doug

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Andrew Davis]

On 12/5/23 9:22 AM, Nishanth Menon wrote:

On 08:46-20231205, Andrew Davis wrote:

On 12/4/23 1:29 PM, Nishanth Menon wrote:

On 15:59-20231201, Dhruva Gole wrote:

Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
requirement for this SoC

Signed-off-by: Dhruva Gole 
---
   doc/board/beagle/am62x_beagleplay.rst | 1 -
   1 file changed, 1 deletion(-)

diff --git a/doc/board/beagle/am62x_beagleplay.rst 
b/doc/board/beagle/am62x_beagleplay.rst
index 7784e62b0b71..50d7d3c620d7 100644
--- a/doc/board/beagle/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
 # we dont use any extra TFA parameters
 unset TFA_EXTRA_ARGS
 export OPTEE_PLATFORM=k3-am62x
-  export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
   .. include::  ../ti/am62x_sk.rst
   :start-after: .. am62x_evm_rst_include_start_build_steps
--
2.34.1


NAK. RNG is needed to seed standard distros.


You have this backwards, setting WITH_SOFTWARE_PRNG=y forces the SW
RNG, disabling the HW RNG. Without this line the HW RNG is the default.



That is not the rationale with which the series was posted. I would
prefer we use HW RNG by default. but as I understand there are a bunch
of f/w bugs preventing us from doing so. if they are resolved, then the
commit message argument should be that the bugs are fixed, so we can
easily use then with f/w version x.y.z onwards.


There was a single FW bug that caused suspend/resume to fail when OP-TEE
was using the HW RNG. The HW RNG always worked, disabling it was a hack
that allowed us to still demo suspend/resume, not sure how that ended up
in this documentation.

The fact we disabled a security feature to workaround a non-security bug
shows a lack of good judgement on our part IMHO. Product security is our
top priority.

Andrew

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

On Tue, 5 Dec 2023 at 21:49, Soeren Moch  wrote:

> On 05.12.23 14:15, Maxim Uvarov wrote:
>
> I think I solved the size issue on all the boards.
>
> Key changes:
> 1. remove compilation of original ping.c and tftp.c (tftp had also server
> code, so I will partially bring it back.)
>
> Interesting.
> @Tom: Is there other server code in u-boot, that is enabled by default
> (and can be used to reclaim code space)?
> Fur sure I do not need u-boot to act as server for tftp (maye nfs, others).
>

Maybe I need to be more clear about this. reference to code from tftp.c and
ping.c exist in net.c, test/image/spl_load_net.c, test.dm/dsa.c,
test/dm/eth.c.
And even if that code is not used (replaced with lwip calls to the same
commands in my case) it adds additional size. Even enabled LTO does not see
direct difference.



> 2. LTO=y
> 3. CONFIG_LOGLEVEL=3 instead of 4.
> 4. CONFIG_CMD_DATE is not set
> 5. CONFIG_CMD_LICENSE is not set
> 6. CONFIG_CMD_PING (if 1-6 did not help).
>
> And these changes were enough for CI tagrets to build.
> I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for
> other boards to test.
>
> For example for this tbs2910 board changes are:
>
> Disabling CMD_DATE is unfortunate. This can help to debug RTC problems
> (already used it for this purpose).
> And, if we are that close to the size limit, than maybe we can get away
> for this series, but for sure will run into trouble for every other small
> change to u-boot core/driver code.
>
> Regards,
> Soeren
>

The problem is that for many targets the limit is 1MB. U-Boot in some
minimal configuration is about 500kb. But U-boot with EFI, USB, Eth
drivers,  MMC, RTC, and all the commands is 900+ kb and very close to 1MB.
Most of the new features are enabled by default. I.e. they do not exist in
_defconfig and appear in the resulting .config automatically.  I would say
that for some small targets things like EFI, Secure boot, TPM, Updates and
many others are not needed. But if new features will appear by default very
soon we will see limits.

BR,
Maxim.

>
> --- a/configs/tbs2910_defconfig
> +++ b/configs/tbs2910_defconfig
> @@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
>  CONFIG_LTO=y
>  CONFIG_HAS_BOARD_SIZE_LIMIT=y
>  CONFIG_BOARD_SIZE_LIMIT=392192
> +CONFIG_TIMESTAMP=y (this was added by savedefconfig)
>  # CONFIG_BOOTSTD is not set
>  CONFIG_SUPPORT_RAW_INITRD=y
>  CONFIG_BOOTDELAY=3
> @@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; then
> run bootcmd_up2; else r
>  CONFIG_USE_PREBOOT=y
>  CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
>  CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"
> +CONFIG_LOGLEVEL=3
>  CONFIG_PRE_CONSOLE_BUFFER=y
>  CONFIG_HUSH_PARSER=y
>  CONFIG_SYS_PROMPT="Matrix U-Boot> "
> @@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y
>  CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_CACHE=y
> -CONFIG_CMD_TIME=y
> +# CONFIG_CMD_DATE is not set
>  CONFIG_CMD_SYSBOOT=y
>  # CONFIG_CMD_VIDCONSOLE is not set
>  CONFIG_CMD_EXT2=y
>
> BR,
> Maxim.
>
>
> On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov 
> wrote:
>
>>
>>
>> On Tue, 28 Nov 2023 at 03:20, Soeren Moch  wrote:
>>
>>> On 27.11.23 14:11, Tom Rini wrote:
>>> > On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov wrote:
>>> >
>>> >> Increase allowed binary size to fit lwip code.
>>> >>
>>> >> Signed-off-by: Maxim Uvarov 
>>> >> ---
>>> >>   configs/tbs2910_defconfig | 2 +-
>>> >>   1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
>>> >> index 8fbe84f1d2..ce40efa9ab 100644
>>> >> --- a/configs/tbs2910_defconfig
>>> >> +++ b/configs/tbs2910_defconfig
>>> >> @@ -17,7 +17,7 @@ CONFIG_SYS_MEMTEST_START=0x1000
>>> >>   CONFIG_SYS_MEMTEST_END=0x2f40
>>> >>   CONFIG_LTO=y
>>> >>   CONFIG_HAS_BOARD_SIZE_LIMIT=y
>>> >> -CONFIG_BOARD_SIZE_LIMIT=392192
>>> >> +CONFIG_BOARD_SIZE_LIMIT=417792
>>> >>   # CONFIG_BOOTSTD is not set
>>> >>   CONFIG_SUPPORT_RAW_INITRD=y
>>> >>   CONFIG_BOOTDELAY=3
>>> > This is another case where the binary size is a fairly hard limit. You
>>> > forgot to cc the board maintainer here (and I assume the rest of the
>>> > series too) for these config changes.
>>> ThanksTom for sending a notification to me.
>>>
>>> Yes, the CONFIG_BOARD_SIZE_LIMIT is a hard limit and this patch in its
>>> current form will break tbs2910 support and even brick the board for
>>> some configurations. So NAK for this patch.
>>> > I think on this platform it's not
>>> > impossible (like it is on am335x where I just replied) but really
>>> > difficult. I'll let Soeren comment on if switching the network stack to
>>> > lwip is the kind of feature enhancement that warrants the pain of
>>> > dealing with the size change here or not.
>>> Network boot is no important feature for this board and not used in
>>> the default boot configuration. But network support always was part
>>> of the config, may be used by some users, and is at least required
>>> to communicate the 

[PATCH v5 8/8] doc: spl: Add info regarding memory reservation

[Devarsh Thakkar]

Add details regarding scheme which need to be followed in SPL and
further stages for those regions which need to be preserved across
bootstages.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V1->V3:
No change.

V4:
Split this to separate patch and add more details regarding
memory reservation scheme that needs to be followed at SPL.

V5:
Add Reviewed-By
---
 doc/develop/spl.rst | 28 
 1 file changed, 28 insertions(+)

diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index 814530d348..0a3e572310 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -173,3 +173,31 @@ cflow will spit out a number of warnings as it does not 
parse
 the config files and picks functions based on #ifdef.  Parsing the '.i'
 files instead introduces another set of headaches.  These warnings are
 not usually important to understanding the flow, however.
+
+
+Reserving memory in SPL
+---
+
+If memory needs to be reserved in RAM during SPL stage with the requirement 
that
+the SPL reserved memory remains preserved across further boot stages too
+then it needs to be reserved mandatorily starting from end of RAM. This is to
+ensure that further stages can simply skip this region before carrying out
+further reservations or updating the relocation address.
+
+Also out of these regions which are to be preserved across further stages of
+boot, video framebuffer memory region must be reserved first starting from
+end of RAM for which helper function spl_reserve_video_from_ram_top is provided
+which makes sure that video memory is placed at top of reservation area with
+further reservations below it.
+
+The corresponding information of reservation for those regions can be passed to
+further boot stages using a bloblist. For e.g. the information for
+framebuffer area reserved by SPL can be passed onto U-boot using
+BLOBLISTT_U_BOOT_VIDEO.
+
+The further boot stages need to parse each of the bloblist passed from SPL 
stage
+starting from video bloblist and skip this whole SPL reserved memory area from
+end of RAM as per the bloblists received, before carrying out further
+reservations or updating the relocation address. For e.g, U-boot proper uses
+function "setup_relocaddr_from_bloblist" to parse the bloblists passed from
+previous stage and skip the memory reserved from previous stage accordingly.
-- 
2.34.1

[PATCH v5 7/8] doc: spl: Add info for missing Kconfigs

[Devarsh Thakkar]

Add info regarding splash screen, video, bloblist and GPIO related
Kconfigs which were missing in the documentation.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2: No change
V3: No change
V4: Patch split from parent
V5: Add Reviewed-by
---
 doc/develop/spl.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index 76e87f07c7..814530d348 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -65,6 +65,15 @@ CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/raw/nand_spl_load.o)
 CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
 CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
 CONFIG_SPL_WATCHDOG (drivers/watchdog/libwatchdog.o)
+CONFIG_SPL_SYSCON (drivers/core/syscon-uclass.o)
+CONFIG_SPL_GZIP (lib/gzip.o)
+CONFIG_SPL_VIDEO (drivers/video/video-uclass.o 
drivers/video/vidconsole-uclass.o)
+CONFIG_SPL_SPLASH_SCREEN (common/splash.o)
+CONFIG_SPL_SPLASH_SOURCE (common/splash_source.o)
+CONFIG_SPL_GPIO (drivers/gpio)
+CONFIG_SPL_DM_GPIO (drivers/gpio/gpio-uclass.o)
+CONFIG_SPL_BMP (drivers/video/bmp.o)
+CONFIG_SPL_BLOBLIST (common/bloblist.o)
 
 Adding SPL-specific code
 
-- 
2.34.1

[PATCH v5 5/8] video: Skip framebuffer reservation if already reserved

[Devarsh Thakkar]

Skip framebufer reservation if it was already reserved from previous
stage and whose information was passed using a bloblist.

Return error in case framebuffer information received from bloblist is
invalid i.e NULL or empty.

While at it, improve the debug message to make it more clear that
address in discussion is of framebuffer and not bloblist and also match
it with printing scheme followed in video_reserve function.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2:
- Add debug prints
- Fix commenting style
V3:
- Fix commenting style
V4:
- Remove extra checks on gd for video data in video_reserve
- Add check and return error if video handoff provided info is invalid
- Improve debug message
- Remove Reviewed-by due to additional changes per review comments
V5:
 - Use PHASE_BOARD_F to check code running in U-boot proper context
 - Add Reviewed-By
---
 common/board_f.c |  8 ++--
 drivers/video/video-uclass.c | 10 --
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index acf802c9cb..442b8349d0 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -407,11 +407,15 @@ static int reserve_video_from_videoblob(void)
 {
if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL) {
struct video_handoff *ho;
+   int ret = 0;
 
ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
if (!ho)
-   return log_msg_ret("blf", -ENOENT);
-   video_reserve_from_bloblist(ho);
+   return log_msg_ret("Missing video bloblist", -ENOENT);
+
+   ret = video_reserve_from_bloblist(ho);
+   if (ret)
+   return log_msg_ret("Invalid Video handoff info", ret);
 
/* Sanity check fb from blob is before current relocaddr */
if (likely(gd->relocaddr > (unsigned long)ho->fb))
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index f743ed74c8..d620a29c25 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -123,6 +123,9 @@ int video_reserve(ulong *addrp)
struct udevice *dev;
ulong size;
 
+   if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() == 
PHASE_BOARD_F)
+   return 0;
+
gd->video_top = *addrp;
for (uclass_find_first_device(UCLASS_VIDEO, );
 dev;
@@ -208,11 +211,14 @@ int video_fill_part(struct udevice *dev, int xstart, int 
ystart, int xend,
 
 int video_reserve_from_bloblist(struct video_handoff *ho)
 {
+   if (!ho->fb || ho->size == 0)
+   return -ENOENT;
+
gd->video_bottom = ho->fb;
gd->fb_base = ho->fb;
gd->video_top = ho->fb + ho->size;
-   debug("Reserving %luk for video using blob at: %08x\n",
- ((unsigned long)ho->size) >> 10, (u32)ho->fb);
+   debug("%s: Reserving %lx bytes at %08x as per bloblist received\n",
+ __func__, (unsigned long)ho->size, (u32)ho->fb);
 
return 0;
 }
-- 
2.34.1

[PATCH v5 6/8] video: Fill video handoff in video post probe

[Devarsh Thakkar]

Fill video handoff fields in video_post_probe as at this point we have
full framebuffer-related information.

Also fill all the fields available in video hand-off struct as those
were missing earlier and U-boot framework expects them to be filled for
some of the functionalities.

While filling framebuffer size in video hand-off structure use the
actual framebuffer region size as derived from gd->video_top and
gd->video_bottom instead of directly using the size populated in
video_uc_plat as it contains unaligned size.

Reported-by: Simon Glass 
Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2:
- No change

V3:
- Fix commit message per review comment
- Add a note explaining assumption of single framebuffer

V4:
- Wrap message to 72 chars

V5:
- Add Reviewed-by and comments for framebuffer size usage
---
 drivers/video/video-uclass.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index d620a29c25..3571e62ba2 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -144,16 +144,6 @@ int video_reserve(ulong *addrp)
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
  gd->video_top);
 
-   if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(VIDEO_HANDOFF)) {
-   struct video_handoff *ho;
-
-   ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
-   if (!ho)
-   return log_msg_ret("blf", -ENOENT);
-   ho->fb = *addrp;
-   ho->size = size;
-   }
-
return 0;
 }
 
@@ -552,6 +542,26 @@ static int video_post_probe(struct udevice *dev)
 
priv->fb_size = priv->line_length * priv->ysize;
 
+   /*
+* Set up video handoff fields for passing video blob to next stage
+* NOTE:
+* This assumes that reserved video memory only uses a single 
framebuffer
+*/
+   if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+   struct video_handoff *ho;
+
+   ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+   if (!ho)
+   return log_msg_ret("blf", -ENOENT);
+   ho->fb = gd->video_bottom;
+   /* Fill aligned size here as calculated in video_reserve() */
+   ho->size = gd->video_top - gd->video_bottom;
+   ho->xsize = priv->xsize;
+   ho->ysize = priv->ysize;
+   ho->line_length = priv->line_length;
+   ho->bpix = priv->bpix;
+   }
+
if (IS_ENABLED(CONFIG_VIDEO_COPY) && plat->copy_base)
priv->copy_fb = map_sysmem(plat->copy_base, plat->size);
 
-- 
2.34.1

[PATCH v5 4/8] common/board_f: Catch bloblist before starting reservations

[Devarsh Thakkar]

Start reservations needed for init sequence only after catching
bloblists from previous stage.

This is to avoid catching bloblists in the middle causing gaps while
u-boot is reserving.

Adjust the relocaddr as per video hand-off information received from
previous stage so that further reservations start only after regions
reserved for previous stages

Skip reservation for video memory if it was already filled by a
bloblist.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2: Fix typo in commit title and checkpatch warnings/checks
V3: No change
V4: Add Reviewed-by
V5: No change
---
 common/board_f.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index d4d7d01f8f..acf802c9cb 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -403,7 +403,7 @@ __weak int arch_reserve_mmu(void)
return 0;
 }
 
-static int reserve_video(void)
+static int reserve_video_from_videoblob(void)
 {
if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL) {
struct video_handoff *ho;
@@ -412,8 +412,34 @@ static int reserve_video(void)
if (!ho)
return log_msg_ret("blf", -ENOENT);
video_reserve_from_bloblist(ho);
-   gd->relocaddr = ho->fb;
-   } else if (CONFIG_IS_ENABLED(VIDEO)) {
+
+   /* Sanity check fb from blob is before current relocaddr */
+   if (likely(gd->relocaddr > (unsigned long)ho->fb))
+   gd->relocaddr = ho->fb;
+   }
+
+   return 0;
+}
+
+/*
+ * Check if any bloblist received specifying reserved areas from previous 
stage and adjust
+ * gd->relocaddr accordingly, so that we start reserving after pre-reserved 
areas
+ * from previous stage.
+ *
+ * NOTE:
+ * IT is recommended that all bloblists from previous stage are reserved from 
ram_top
+ * as next stage will simply start reserving further regions after them.
+ */
+static int setup_relocaddr_from_bloblist(void)
+{
+   reserve_video_from_videoblob();
+
+   return 0;
+}
+
+static int reserve_video(void)
+{
+   if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
 
@@ -923,6 +949,7 @@ static const init_fnc_t init_sequence_f[] = {
reserve_pram,
 #endif
reserve_round_4k,
+   setup_relocaddr_from_bloblist,
arch_reserve_mmu,
reserve_video,
reserve_trace,
-- 
2.34.1

[PATCH v5 3/8] board: ti: am62x: evm: Remove video_setup from spl_board_init

[Devarsh Thakkar]

Remove video_setup from evm_init sequence since video memory is getting
called at an earlier place to make sure video memory is reserved at
the end of RAM.

Suggested-by: Simon Glass 
Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2: No change
V3: No change
V4: Add Reviewed-by
V5: No change
---
 board/ti/am62x/evm.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad93908840..88e02155ee 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -60,27 +60,9 @@ int dram_init_banksize(void)
 }
 
 #if defined(CONFIG_SPL_BUILD)
-static int video_setup(void)
-{
-   if (CONFIG_IS_ENABLED(VIDEO)) {
-   ulong addr;
-   int ret;
-
-   addr = gd->relocaddr;
-   ret = video_reserve();
-   if (ret)
-   return ret;
-   debug("Reserving %luk for video at: %08lx\n",
- ((unsigned long)gd->relocaddr - addr) >> 10, addr);
-   gd->relocaddr = addr;
-   }
-
-   return 0;
-}
 
 void spl_board_init(void)
 {
-   video_setup();
enable_caches();
if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
splash_display();
-- 
2.34.1

[PATCH v5 2/8] arm: mach-k3: common: Reserve video memory from end of the RAM

[Devarsh Thakkar]

Setup video memory before page table reservation using
"spl_reserve_video_from_ram_top" which ensures framebuffer memory gets
reserved from the end of RAM.

This is done to enable the next stage to directly skip the
pre-reserved area from previous stage right from the end of RAM without
having to make any gaps/holes to accommodate those regions which was the
case before as previous stage reserved region not from the end of RAM.

Use gd->ram_top instead of local ram_top and update gd->reloc_addr after
each reservation to ensure further regions are reserved properly.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Nikhil M Jain 
---
V2:
 - Make a generic function "spl_reserve_video" under
   common/spl which can be re-used by other platforms too
   for reserving video memory from spl.

V3:
 - Change spl_reserve_video to spl_reserve_video_from_ram_top
   which enforce framebuffer reservation from end of RAM
 - Use gd->ram_top instead of local ram_top and update
   gd->reloc_addr after each reservation
 - Print error message on framebuffer reservation

V4:
 - Split this into a separate patch

V5:
 - Add Reviewed-by
---
 arch/arm/mach-k3/common.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fd400e7e3d..42ceeb5296 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -524,19 +524,26 @@ void remove_fwl_configs(struct fwl_data *fwl_data, size_t 
fwl_data_size)
 void spl_enable_cache(void)
 {
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
-   phys_addr_t ram_top = CFG_SYS_SDRAM_BASE;
+   gd->ram_top = CFG_SYS_SDRAM_BASE;
+   int ret = 0;
 
dram_init();
 
/* reserve TLB table */
gd->arch.tlb_size = PGTABLE_SIZE;
 
-   ram_top += get_effective_memsize();
+   gd->ram_top += get_effective_memsize();
/* keep ram_top in the 32-bit address space */
-   if (ram_top >= 0x1)
-   ram_top = (phys_addr_t) 0x1;
+   if (gd->ram_top >= 0x1)
+   gd->ram_top = (phys_addr_t)0x1;
 
-   gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+   gd->relocaddr = gd->ram_top;
+
+   ret = spl_reserve_video_from_ram_top();
+   if (ret)
+   panic("Failed to reserve framebuffer memory (%d)\n", ret);
+
+   gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
gd->arch.tlb_addr &= ~(0x1 - 1);
debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
  gd->arch.tlb_addr + gd->arch.tlb_size);
-- 
2.34.1

[PATCH v5 1/8] spl: Enforce framebuffer reservation from end of RAM

[Devarsh Thakkar]

Add an API which enforces framebuffer reservation from end of RAM.
This is done so that next stage can directly skip this region before
carrying out further reservations.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Simon Glass 
---
V2:
No change.

V3:
Change spl_reserve_video to spl_reserve_video_from_ram_top
which enforce framebuffer reservation from end of RAM.

V4:
Split this to an independent patch with more details added
in comments for API in header file.

V5:
Add Reviewed-By
---
 common/spl/spl.c | 19 +++
 include/spl.h| 10 ++
 2 files changed, 29 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 3ce5bfeec8..b65c439e7a 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 DECLARE_BINMAN_MAGIC_SYM;
@@ -152,6 +153,24 @@ void spl_fixup_fdt(void *fdt_blob)
 #endif
 }
 
+int spl_reserve_video_from_ram_top(void)
+{
+   if (CONFIG_IS_ENABLED(VIDEO)) {
+   ulong addr;
+   int ret;
+
+   addr = gd->ram_top;
+   ret = video_reserve();
+   if (ret)
+   return ret;
+   debug("Reserving %luk for video at: %08lx\n",
+ ((unsigned long)gd->relocaddr - addr) >> 10, addr);
+   gd->relocaddr = addr;
+   }
+
+   return 0;
+}
+
 ulong spl_get_image_pos(void)
 {
if (!CONFIG_IS_ENABLED(BINMAN_UBOOT_SYMBOLS))
diff --git a/include/spl.h b/include/spl.h
index 0952188901..043875f10f 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -889,6 +889,16 @@ int spl_usb_load(struct spl_image_info *spl_image,
 
 int spl_ymodem_load_image(struct spl_image_info *spl_image,
  struct spl_boot_device *bootdev);
+/**
+ * spl_reserve_video_from_ram_top() - Reserve framebuffer memory from end of 
RAM
+ *
+ * This enforces framebuffer reservation at SPL stage from end of RAM so that
+ * next stage can directly skip this pre-reserved area before carrying out
+ * further reservations. The allocation address is stored in struct 
video_uc_plat.
+ *
+ * Return: 0 on success, otherwise error code
+ */
+int spl_reserve_video_from_ram_top(void);
 
 /**
  * spl_invoke_atf - boot using an ARM trusted firmware image
-- 
2.34.1

[PATCH v5 0/8] Move framebuffer reservation for SPL to RAM end

[Devarsh Thakkar]

Move video memory reservation for SPL at end of RAM so that it does
not interefere with reservations for next stage so that the next stage
need not have holes in between for passed regions and instead it can
maintain continuity in reservations.

Also catch the bloblist before starting reservations to avoid the same
problem.

While at it, also fill missing fields in video handoff struct before
passing it to next stage.

This is as per discussions at :
For moving SPL framebuffer reservation at end of RAM:

https://lore.kernel.org/all/capnjgz3xsoe_g3yrqwuavoivjufz+yqgkor0ztvxgt9vk8t...@mail.gmail.com/

For filling missing video handoff fields :
https://lore.kernel.org/all/CAPnjgZ1Hs0rNf0JDirp6YPsOQ5=qqqsp9g9qrwlooasuv8a...@mail.gmail.com/

Changelog:
V2:
- Make a generic function to reserve video memory at SPL stage.
- Add debug prints while skipping framebuffer allocation at uboot.
- Correct commenting style as suggested.

V3:
- Change spl_reserve_video to spl_reserve_video_from_ram_top
  which enforce framebuffer reservation from end of RAM.
- Use gd->ram_top instead of local ram_top and update
  gd->reloc_addr after each reservation.
- Print error message on framebuffer reservation.
- Update SPL doc with spl splash screen specific info.

V4:
- Split patches into atomic commits.
- Remove duplicate check for video blob passed addresses and error out
  if invalid address/size received from blob.
- Improve SPL documentation memory reservation scheme and print message
  for video memory reservation from bloblist. 
- Add Reviewed-By.

V5:
 - Add comment for filling video handoff size with aligned size
 - Use PHASE_BOARD_F while checking for U-boot proper stage
 - Add Reviewed-by

Test logs:
https://gist.github.com/devarsht/30a3c1591270c9ebae00714b48d33058

Devarsh Thakkar (8):
  spl: Enforce framebuffer reservation from end of RAM
  arm: mach-k3: common: Reserve video memory from end of the RAM
  board: ti: am62x: evm: Remove video_setup from spl_board_init
  common/board_f: Catch bloblist before starting reservations
  video: Skip framebuffer reservation if already reserved
  video: Fill video handoff in video post probe
  doc: spl: Add info for missing Kconfigs
  doc: spl: Add info regarding memory reservation

 arch/arm/mach-k3/common.c| 17 ++-
 board/ti/am62x/evm.c | 18 
 common/board_f.c | 41 +++-
 common/spl/spl.c | 19 +
 doc/develop/spl.rst  | 37 
 drivers/video/video-uclass.c | 40 ---
 include/spl.h| 10 +
 7 files changed, 142 insertions(+), 40 deletions(-)

-- 
2.34.1

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Soeren Moch]

On 05.12.23 14:15, Maxim Uvarov wrote:

I think I solved the size issue on all the boards.

Key changes:
1. remove compilation of original ping.c and tftp.c (tftp had also
server code, so I will partially bring it back.)

Interesting.
@Tom: Is there other server code in u-boot, that is enabled by default
(and can be used to reclaim code space)?
Fur sure I do not need u-boot to act as server for tftp (maye nfs, others).

2. LTO=y
3. CONFIG_LOGLEVEL=3 instead of 4.
4. CONFIG_CMD_DATE is not set
5. CONFIG_CMD_LICENSE is not set
6. CONFIG_CMD_PING (if 1-6 did not help).

And these changes were enough for CI tagrets to build.
I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking
for other boards to test.

For example for this tbs2910 board changes are:

Disabling CMD_DATE is unfortunate. This can help to debug RTC problems
(already used it for this purpose).
And, if we are that close to the size limit, than maybe we can get away
for this series, but for sure will run into trouble for every other
small change to u-boot core/driver code.

Regards,
Soeren


--- a/configs/tbs2910_defconfig
+++ b/configs/tbs2910_defconfig
@@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
 CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
 CONFIG_BOARD_SIZE_LIMIT=392192
+CONFIG_TIMESTAMP=y (this was added by savedefconfig)
 # CONFIG_BOOTSTD is not set
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOOTDELAY=3
@@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1;
then run bootcmd_up2; else r
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
 CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"
+CONFIG_LOGLEVEL=3
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Matrix U-Boot> "
@@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
-CONFIG_CMD_TIME=y
+# CONFIG_CMD_DATE is not set
 CONFIG_CMD_SYSBOOT=y
 # CONFIG_CMD_VIDCONSOLE is not set
 CONFIG_CMD_EXT2=y

BR,
Maxim.


On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov 
wrote:



On Tue, 28 Nov 2023 at 03:20, Soeren Moch  wrote:

On 27.11.23 14:11, Tom Rini wrote:
> On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov wrote:
>
>> Increase allowed binary size to fit lwip code.
>>
>> Signed-off-by: Maxim Uvarov 
>> ---
>>   configs/tbs2910_defconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/tbs2910_defconfig
b/configs/tbs2910_defconfig
>> index 8fbe84f1d2..ce40efa9ab 100644
>> --- a/configs/tbs2910_defconfig
>> +++ b/configs/tbs2910_defconfig
>> @@ -17,7 +17,7 @@ CONFIG_SYS_MEMTEST_START=0x1000
>>   CONFIG_SYS_MEMTEST_END=0x2f40
>>   CONFIG_LTO=y
>>   CONFIG_HAS_BOARD_SIZE_LIMIT=y
>> -CONFIG_BOARD_SIZE_LIMIT=392192
>> +CONFIG_BOARD_SIZE_LIMIT=417792
>>   # CONFIG_BOOTSTD is not set
>>   CONFIG_SUPPORT_RAW_INITRD=y
>>   CONFIG_BOOTDELAY=3
> This is another case where the binary size is a fairly hard
limit. You
> forgot to cc the board maintainer here (and I assume the
rest of the
> series too) for these config changes.
ThanksTom for sending a notification to me.

Yes, the CONFIG_BOARD_SIZE_LIMIT is a hard limit and this
patch in its
current form will break tbs2910 support and even brick the
board for
some configurations. So NAK for this patch.
> I think on this platform it's not
> impossible (like it is on am335x where I just replied) but
really
> difficult. I'll let Soeren comment on if switching the
network stack to
> lwip is the kind of feature enhancement that warrants the
pain of
> dealing with the size change here or not.
Network boot is no important feature for this board and not
used in
the default boot configuration. But network support always was
part
of the config, may be used by some users, and is at least required
to communicate the ethernet address to linux.

So I'm not interested in a new network stack for this board, but
also cannot disable network support completely. This seems to be a
problem for this patch series, since networking support
implies LWIP
now.


Thanks Soeren for the explanation. Then yes, something more
advanced is needed
to be done here.

The question for me is, why is the new network stack consuming so
much space, with only a few enabled commands? Is the whole library
linked in with some unused features (the cover letter mentions
much
more than what seems to be used in the converted commands). Or is
the old network stack linked in in parallel to the new one? Can
we save space here?


Yes, the old code is still there. 

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Nishanth Menon]

On 08:46-20231205, Andrew Davis wrote:
> On 12/4/23 1:29 PM, Nishanth Menon wrote:
> > On 15:59-20231201, Dhruva Gole wrote:
> > > Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
> > > requirement for this SoC
> > > 
> > > Signed-off-by: Dhruva Gole 
> > > ---
> > >   doc/board/beagle/am62x_beagleplay.rst | 1 -
> > >   1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/doc/board/beagle/am62x_beagleplay.rst 
> > > b/doc/board/beagle/am62x_beagleplay.rst
> > > index 7784e62b0b71..50d7d3c620d7 100644
> > > --- a/doc/board/beagle/am62x_beagleplay.rst
> > > +++ b/doc/board/beagle/am62x_beagleplay.rst
> > > @@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
> > > # we dont use any extra TFA parameters
> > > unset TFA_EXTRA_ARGS
> > > export OPTEE_PLATFORM=k3-am62x
> > > -  export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
> > >   .. include::  ../ti/am62x_sk.rst
> > >   :start-after: .. am62x_evm_rst_include_start_build_steps
> > > -- 
> > > 2.34.1
> > > 
> > NAK. RNG is needed to seed standard distros.
> 
> You have this backwards, setting WITH_SOFTWARE_PRNG=y forces the SW
> RNG, disabling the HW RNG. Without this line the HW RNG is the default.


That is not the rationale with which the series was posted. I would
prefer we use HW RNG by default. but as I understand there are a bunch
of f/w bugs preventing us from doing so. if they are resolved, then the
commit message argument should be that the bugs are fixed, so we can
easily use then with f/w version x.y.z onwards.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH 2/2] tee: optee: don't enumerate services if there ain't any

[Jens Wiklander]

On Wed, Nov 29, 2023 at 1:37 PM Etienne Carriere
 wrote:
>
> Change optee driver service enumeration to not enumerate (and
> allocate a zero sized shared memory buffer) when OP-TEE
> reports that there is no service to enumerate.
>
> This change fixes an existing issue that occurs when the such zero
> sized shared memory buffer allocated from malloc() has a physical
> address of offset 0 of a physical 4kB page. In such case, OP-TEE
> secure world refuses to register the zero-sized shared memory
> area and makes U-Boot optee service enumeration to fail.
>
> Fixes: 94ccfb78a4d6 ("drivers: tee: optee: discover OP-TEE services")
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 5308dd58ce..47f845cffe 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -139,6 +139,11 @@ static int enum_services(struct udevice *dev, struct 
> tee_shm **shm, size_t *coun
> if (ret)
> return ret;
>
> +   if (!shm_size) {
> +   *count = 0;
> +   return 0;
> +   }
> +
> ret = tee_shm_alloc(dev, shm_size, 0, shm);
> if (ret) {
> dev_err(dev, "Failed to allocated shared memory: %d\n", ret);
> @@ -185,14 +190,15 @@ static int bind_service_drivers(struct udevice *dev)
>
> ret = enum_services(dev, _list, _count, tee_sess,
> PTA_CMD_GET_DEVICES);
> -   if (!ret)
> +   if (!ret && service_count)
> ret = bind_service_list(dev, service_list, service_count);
>
> tee_shm_free(service_list);
> +   service_list = NULL;
>
> ret2 = enum_services(dev, _list, _count, tee_sess,
>  PTA_CMD_GET_DEVICES_SUPP);
> -   if (!ret2)
> +   if (!ret2 && service_count)
> ret2 = bind_service_list(dev, service_list, service_count);
>
> tee_shm_free(service_list);
> --
> 2.25.1
>

Re: [PATCH 1/2] tee: optee: don't fail on services enumeration failure

[Jens Wiklander]

On Wed, Nov 29, 2023 at 1:37 PM Etienne Carriere
 wrote:
>
> Change optee probe function to only warn when service enumeration
> sequence fails instead of reporting an optee driver probe failure.
> Indeed U-Boot can still use OP-TEE even if some OP-TEE services are
> not discovered.
>
> Fixes: 94ccfb78a4d6 ("drivers: tee: optee: discover OP-TEE services")
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 9a9b697e91..5308dd58ce 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -841,7 +841,7 @@ static int optee_probe(struct udevice *dev)
> if (IS_ENABLED(CONFIG_OPTEE_SERVICE_DISCOVERY)) {
> ret = bind_service_drivers(dev);
> if (ret)
> -   return ret;
> +   dev_warn(dev, "optee service enumeration failed: 
> %d\n", ret);
> } else if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> /*
>  * Discovery of TAs on the TEE bus is not supported in U-Boot:
> --
> 2.25.1
>

Looks good.
Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Andrew Davis]

On 12/4/23 1:29 PM, Nishanth Menon wrote:

On 15:59-20231201, Dhruva Gole wrote:

Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
requirement for this SoC

Signed-off-by: Dhruva Gole 
---
  doc/board/beagle/am62x_beagleplay.rst | 1 -
  1 file changed, 1 deletion(-)

diff --git a/doc/board/beagle/am62x_beagleplay.rst 
b/doc/board/beagle/am62x_beagleplay.rst
index 7784e62b0b71..50d7d3c620d7 100644
--- a/doc/board/beagle/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-am62x
-  export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
  
  .. include::  ../ti/am62x_sk.rst

  :start-after: .. am62x_evm_rst_include_start_build_steps
--
2.34.1


NAK. RNG is needed to seed standard distros.


You have this backwards, setting WITH_SOFTWARE_PRNG=y forces the SW
RNG, disabling the HW RNG. Without this line the HW RNG is the default.

Andrew

Re: [PATCH v2] riscv: Add support for AMD/Xilinx MicroBlaze V

[Michal Simek]

On 12/5/23 06:17, padmarao.beg...@microchip.com wrote:

On Mon, 2023-11-06 at 12:56 +0100, Michal Simek wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you
know the content is safe

MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
It is hardware compatible with classic MicroBlaze processor.

The patch contains initial wiring and configuration for initial HW
design
with memory, cpu, interrupt controller, timers and uartlite console
(interrupt controller is listed but U-Boot is not using it).

Provided DT is just describing one configuration and should be taken
only
as example.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Extend commit message
- DT changes, add interrupt controller, check agains dt schema
- The patch for amd,mbv32 compatible string is here
https://lore.kernel.org/r/d442d916204d26f82c1c3a924a4cdfb117960e1b.1699270661.git.michal.si...@amd.com
- The patch for board compatibility is here
https://lore.kernel.org/r/50c277c92c41a582ef171fb75efc6a6a4f860be2.1699271616.git.michal.si...@amd.com

xlnx,xps-intc-1.00.a driver exists in the Linux kernel but DT binding
is
missing. That's something what we need to work on.
arch/arm64/boot/dts/xilinx/xilinx-mbv32.dtb:
/axi/interrupt-controller@4120: failed to match any schema with
compatible: ['xlnx,xps-intc-1.00.a']

Public annoucement is available here if someone is interested.
https://www.xilinx.com/products/design-tools/microblaze-v.html?utm_source=marketo_medium=email_campaign=EN-EM-2023-11-02-New-MicroBlaze-V-Processor_term=btn_tok=NDA5LVdZWC03MjQAAAGPMMJYuPPscCags7WdvOeUSWy-_mC9aOwrobFaZRf5ok_eHoQUvTLBzJdHrkcBId9tQ4a-odfnU91WjUkIxx-iSG4OKGofjK5iZcAiK_VN8_xK

---
  arch/riscv/Kconfig   |   4 +
  arch/riscv/dts/Makefile  |   2 +
  arch/riscv/dts/xilinx-mbv32.dts  | 106
+++
  board/xilinx/Kconfig |   3 +-
  board/xilinx/common/board.c  |   5 ++
  board/xilinx/mbv/Kconfig |  28 +++
  board/xilinx/mbv/MAINTAINERS |   7 ++
  board/xilinx/mbv/Makefile|   5 ++
  board/xilinx/mbv/board.c |  11 +++
  configs/xilinx_mbv32_defconfig   |  30 
  configs/xilinx_mbv32_smode_defconfig |  32 
  include/configs/xilinx_mbv.h |   6 ++
  12 files changed, 238 insertions(+), 1 deletion(-)
  create mode 100644 arch/riscv/dts/xilinx-mbv32.dts
  create mode 100644 board/xilinx/mbv/Kconfig
  create mode 100644 board/xilinx/mbv/MAINTAINERS
  create mode 100644 board/xilinx/mbv/Makefile
  create mode 100644 board/xilinx/mbv/board.c
  create mode 100644 configs/xilinx_mbv32_defconfig
  create mode 100644 configs/xilinx_mbv32_smode_defconfig
  create mode 100644 include/configs/xilinx_mbv.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6d0d812ddb55..67126d96af89 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -39,6 +39,9 @@ config TARGET_TH1520_LPI4A
 bool "Support Sipeed's TH1520 Lichee PI 4A Board"
 select SYS_CACHE_SHIFT_6

+config TARGET_XILINX_MBV
+   bool "Support AMD/Xilinx MicroBlaze V"
+
  endchoice

  config SYS_ICACHE_OFF
@@ -82,6 +85,7 @@ source "board/sifive/unmatched/Kconfig"
  source "board/sipeed/maix/Kconfig"
  source "board/starfive/visionfive2/Kconfig"
  source "board/thead/th1520_lpi4a/Kconfig"
+source "board/xilinx/mbv/Kconfig"

  # platform-specific options below
  source "arch/riscv/cpu/andesv5/Kconfig"
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index be6c8a422729..b05bb5607f06 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-
unmatched-a00.dtb
  dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
  dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += jh7110-starfive-
visionfive-2.dtb
  dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
+dtb-$(CONFIG_TARGET_XILINX_MBV) += xilinx-mbv32.dtb
+
  include $(srctree)/scripts/Makefile.dts

  targets += $(dtb-y)
diff --git a/arch/riscv/dts/xilinx-mbv32.dts b/arch/riscv/dts/xilinx-
mbv32.dts
new file mode 100644
index ..6a6b8b694bd1
--- /dev/null
+++ b/arch/riscv/dts/xilinx-mbv32.dts
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for AMD MicroBlaze V
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek 
+ */
+
+/dts-v1/;
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   model = "AMD MicroBlaze V 32bit";
+   compatible = "amd,mbv";
+
+   cpus: cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   timebase-frequency = <10200>;
+   cpu_0: cpu@0 {
+   compatible = "amd,mbv32", "riscv";
+   device_type = "cpu";
+   reg = <0>;
+   riscv,isa = "rv32imafdc";
+   i-cache-size = <32768>;
+   d-cache-size = 

[PATCH v6 9/9] pmic: qcom: dont use dev_read_addr to get USID

[Caleb Connolly]

Linux DTs stuff a value indicating if the USID is a USID or a GSID in the
reg property, the Linux SPMI driver then reads the two address cells
separately. U-boot's dev_read_addr() doesn't know how to handle this, so
use ofnode_read_u32_index() to get just the USID.

The Qcom pmic driver doesn't have support for GSID handling, so just
ignore the second value for now.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt | 94 
 drivers/power/pmic/pmic_qcom.c   | 13 +++-
 2 files changed, 10 insertions(+), 97 deletions(-)

diff --git a/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt 
b/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
deleted file mode 100644
index eb78e3ae7703..
--- a/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-  Qualcomm SPMI PMICs multi-function device bindings
-
-The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084
-PMICs.  These PMICs use a QPNP scheme through SPMI interface.
-QPNP is effectively a partitioning scheme for dividing the SPMI extended
-register space up into logical pieces, and set of fixed register
-locations/definitions within these regions, with some of these regions
-specifically used for interrupt handling.
-
-The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are
-interfaced to the chip via the SPMI (System Power Management Interface) bus.
-Support for multiple independent functions are implemented by splitting the
-16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes
-each. A function can consume one or more of these fixed-size register regions.
-
-Required properties:
-- compatible:  Should contain one of:
-   "qcom,pm660",
-   "qcom,pm660l",
-   "qcom,pm7325",
-   "qcom,pm8004",
-   "qcom,pm8005",
-   "qcom,pm8019",
-   "qcom,pm8028",
-   "qcom,pm8110",
-   "qcom,pm8150",
-   "qcom,pm8150b",
-   "qcom,pm8150c",
-   "qcom,pm8150l",
-   "qcom,pm8226",
-   "qcom,pm8350c",
-   "qcom,pm8841",
-   "qcom,pm8901",
-   "qcom,pm8909",
-   "qcom,pm8916",
-   "qcom,pm8941",
-   "qcom,pm8950",
-   "qcom,pm8953",
-   "qcom,pm8994",
-   "qcom,pm8998",
-   "qcom,pma8084",
-   "qcom,pmd9635",
-   "qcom,pmi8950",
-   "qcom,pmi8962",
-   "qcom,pmi8994",
-   "qcom,pmi8998",
-   "qcom,pmk8002",
-   "qcom,pmk8350",
-   "qcom,pmr735a",
-   "qcom,smb2351",
-   or generalized "qcom,spmi-pmic".
-- reg: Specifies the SPMI USID slave address for this device.
-   For more information see:
-   Documentation/devicetree/bindings/spmi/spmi.yaml
-
-Required properties for peripheral child nodes:
-- compatible:  Should contain "qcom,xxx", where "xxx" is a peripheral name.
-
-Optional properties for peripheral child nodes:
-- interrupts:  Interrupts are specified as a 4-tuple. For more information
-   see:
-   
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
-- interrupt-names: Corresponding interrupt name to the interrupts property
-
-Each child node of SPMI slave id represents a function of the PMIC. In the
-example below the rtc device node represents a peripheral of pm8941
-SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1.
-
-Example:
-
-   spmi {
-   compatible = "qcom,spmi-pmic-arb";
-
-   pm8941@0 {
-   compatible = "qcom,pm8941", "qcom,spmi-pmic";
-   reg = <0x0 SPMI_USID>;
-
-   rtc {
-   compatible = "qcom,rtc";
-   interrupts = <0x0 0x61 0x1 
IRQ_TYPE_EDGE_RISING>;
-   interrupt-names = "alarm";
-   };
-   };
-
-   pm8941@1 {
-   compatible = "qcom,pm8941", "qcom,spmi-pmic";
-   reg = <0x1 SPMI_USID>;
-
-   regulator {
-   compatible = "qcom,regulator";
-   regulator-name = "8941_boost";
-   };
-   };
-   };
diff --git a/drivers/power/pmic/pmic_qcom.c b/drivers/power/pmic/pmic_qcom.c
index ad8daf43f06f..f2ac6494811d 100644
--- a/drivers/power/pmic/pmic_qcom.c
+++ b/drivers/power/pmic/pmic_qcom.c
@@ 

[PATCH v6 8/9] spmi: msm: fix register range names

[Caleb Connolly]

The core and chnl register ranges were swapped on SDM845. Fix it, and
fetch the register ranges by name instead of by index.

Drop the cosmetic "version" variable and clean up the debug logging.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/qcs404-evb.dts|  7 +++--
 arch/arm/dts/sdm845.dtsi   |  2 +-
 doc/device-tree-bindings/spmi/spmi-msm.txt | 26 -
 drivers/spmi/spmi-msm.c| 46 --
 4 files changed, 23 insertions(+), 58 deletions(-)

diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index bd2e303e10f4..07bf7dd0b32f 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -362,9 +362,10 @@
 
spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
-   reg = <0x200f000 0x1000
-  0x240 0x40
-  0x2c0 0x40>;
+   reg = <0x200f000 0x001000>,
+ <0x240 0x80>,
+ <0x2c0 0x80>;
+   reg-names = "core", "chnls", "obsrvr";
#address-cells = <0x1>;
#size-cells = <0x1>;
 
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index a26e9f411ee0..96c9749a52c0 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -63,7 +63,7 @@
reg = <0xc44 0x1100>,
  <0xc60 0x200>,
  <0xe60 0x10>;
-   reg-names = "cnfg", "core", "obsrvr";
+   reg-names = "core", "chnls", "obsrvr";
#address-cells = <0x1>;
#size-cells = <0x1>;
 
diff --git a/doc/device-tree-bindings/spmi/spmi-msm.txt 
b/doc/device-tree-bindings/spmi/spmi-msm.txt
deleted file mode 100644
index ae47673b768b..
--- a/doc/device-tree-bindings/spmi/spmi-msm.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Qualcomm SPMI arbiter/bus driver
-
-This is bus driver for Qualcomm chips that use SPMI to communicate with PMICs.
-
-Required properties:
-- compatible: "qcom,spmi-pmic-arb"
-- reg: Register block adresses and sizes for various parts of device:
-   1) PMIC arbiter channel mapping base (PMIC_ARB_REG_CHNLn)
-   2) SPMI write command (master) registers (PMIC_ARB_CORE_SW_DEC_CHANNELS)
-   3) SPMI read command (observer) registers (PMIC_ARB_CORE_REGISTERS_OBS)
-
-Optional properties (if not set by parent):
-- #address-cells: 0x1 - childs slave ID address
-- #size-cells: 0x1
-
-All PMICs should be placed as a child nodes of bus arbiter.
-Automatic detection of childs is currently not supported.
-
-Example:
-
-spmi@200f000 {
-   compatible = "qcom,spmi-pmic-arb";
-   reg = <0x200f800 0x200 0x240 0x40 0x2c0 0x40>;
-   #address-cells = <0x1>;
-   #size-cells = <0x1>;
-};
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 27a035c0a595..5fe8a70abca7 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -70,7 +70,7 @@ enum pmic_arb_channel {
 
 struct msm_spmi_priv {
phys_addr_t arb_chnl;  /* ARB channel mapping base */
-   phys_addr_t spmi_core; /* SPMI core */
+   phys_addr_t spmi_chnls; /* SPMI channels */
phys_addr_t spmi_obs;  /* SPMI observer */
/* SPMI channel map */
uint8_t channel_map[SPMI_MAX_SLAVES][SPMI_MAX_PERIPH];
@@ -95,10 +95,10 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
 
/* Disable IRQ mode for the current channel*/
writel(0x0,
-  priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
+  priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
 
/* Write single byte */
-   writel(val, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_WDATA);
+   writel(val, priv->spmi_chnls + SPMI_CH_OFFSET(channel) + 
SPMI_REG_WDATA);
 
/* Prepare write command */
reg |= SPMI_CMD_EXT_REG_WRITE_LONG << SPMI_CMD_OPCODE_SHIFT;
@@ -113,12 +113,12 @@ static int msm_spmi_write(struct udevice *dev, int usid, 
int pid, int off,
ch_offset = SPMI_CH_OFFSET(channel);
 
/* Send write command */
-   writel(reg, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
+   writel(reg, priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
 
/* Wait till CMD DONE status */
reg = 0;
while (!reg) {
-   reg = readl(priv->spmi_core + SPMI_CH_OFFSET(channel) +
+   reg = readl(priv->spmi_chnls + SPMI_CH_OFFSET(channel) +
SPMI_REG_STATUS);
}
 
@@ -186,47 +186,37 @@ static struct dm_spmi_ops msm_spmi_ops = {
 static int msm_spmi_probe(struct udevice *dev)
 {
  

[PATCH v6 7/9] gpio: qcom_pmic: drop gpio-count property

[Caleb Connolly]

This property is not part of the dt bindings and all boards use the new
gpio-ranges property instead. Drop support for this.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 doc/device-tree-bindings/gpio/pm8916_gpio.txt | 48 ---
 drivers/gpio/qcom_pmic_gpio.c | 13 +++-
 2 files changed, 5 insertions(+), 56 deletions(-)

diff --git a/doc/device-tree-bindings/gpio/pm8916_gpio.txt 
b/doc/device-tree-bindings/gpio/pm8916_gpio.txt
deleted file mode 100644
index 58185b833524..
--- a/doc/device-tree-bindings/gpio/pm8916_gpio.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Driver for part of pm8916 PMIC - gpio and power/reset keys
-
-This device should be child of SPMI pmic.
-
-1) GPIO driver
-
-Required properties:
-- compatible: "qcom,pm8916-gpio"
-- reg: peripheral ID, size of register block
-- gpio-controller
-- gpio-count: number of GPIOs
-- #gpio-cells: 2
-
-Optional properties:
-- gpio-bank-name: name of bank (as default "pm8916" is used)
-
-Example:
-
-pmic_gpios: gpios@c000 {
-   compatible = "qcom,pm8916-gpio";
-   reg = <0xc000 0x400>;
-   gpio-controller;
-   gpio-count = <4>;
-   #gpio-cells = <2>;
-   gpio-bank-name="pmic";
-};
-
-
-2) Power/Reset key driver
-
-Required properties:
-- compatible: "qcom,pm8916-pwrkey"
-- reg: peripheral ID, size of register block
-- gpio-controller
-- #gpio-cells: 2
-
-Optional properties:
-- gpio-bank-name: name of bank (as default "pm8916_key" is used)
-
-
-Example:
-
-pmic_pon: pon@800 {
-   compatible = "qcom,pm8916-pwrkey";
-   reg = <0x800 0x96>;
-   #gpio-cells = <2>;
-   gpio-controller;
-};
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 5221bd27825e..6167c8411678 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -268,14 +268,11 @@ static int qcom_gpio_of_to_plat(struct udevice *dev)
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
 
-   uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
-   if (!uc_priv->gpio_count) {
-   ret = qcom_gpio_of_parse_ranges(dev);
-   if (ret > 0)
-   uc_priv->gpio_count = ret;
-   else
-   return ret;
-   }
+   ret = qcom_gpio_of_parse_ranges(dev);
+   if (ret > 0)
+   uc_priv->gpio_count = ret;
+   else
+   return ret;
 
uc_priv->bank_name = "pmic";
 

-- 
2.42.1

[PATCH v6 6/9] dts: qcom: adjust pmic gpio to use upstream bindings

[Caleb Connolly]

Use the upstream gpio-ranges property instead of gpio-count, and drop
the bank-name property for Qualcomm boards.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/dragonboard410c.dts | 3 +--
 arch/arm/dts/dragonboard820c.dts | 3 +--
 arch/arm/dts/qcs404-evb.dts  | 3 +--
 arch/arm/dts/sdm845.dtsi | 3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index c41fee977813..6a4e3ccf17b1 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -170,9 +170,8 @@
compatible = "qcom,pm8916-gpio";
reg = <0xc000 0x400>;
gpio-controller;
-   gpio-count = <4>;
+   gpio-ranges = <_gpios 0 0 4>;
#gpio-cells = <2>;
-   gpio-bank-name="pmic";
};
};
 
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 0d9c9f7a4922..146a0af8aafe 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -132,9 +132,8 @@
compatible = "qcom,pm8994-gpio";
reg = <0xc000 0x400>;
gpio-controller;
-   gpio-count = <24>;
+   gpio-ranges = <_gpios 0 0 22>;
#gpio-cells = <2>;
-   gpio-bank-name="pm8994.";
};
};
 
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 84224a8a3d39..bd2e303e10f4 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -378,9 +378,8 @@
compatible = "qcom,pms405-gpio";
reg = <0xc000 0x400>;
gpio-controller;
-   gpio-count = <12>;
+   gpio-ranges = <_gpios 0 0 12>;
#gpio-cells = <2>;
-   gpio-bank-name="pmic";
};
};
};
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index cd5d890e9a45..a26e9f411ee0 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -103,9 +103,8 @@
compatible = "qcom,pm8998-gpio";
reg = <0xc000 0x1a00>;
gpio-controller;
-   gpio-count = <21>;
+   gpio-ranges = <_gpios 0 0 26>;
#gpio-cells = <2>;
-   gpio-bank-name = "pm8998.";
};
};
 

-- 
2.42.1

[PATCH v6 5/9] gpio: qcom_pmic: support upstream DT

[Caleb Connolly]

Upstream uses the gpio-ranges property to define the number of GPIOs,
support for parsing this when gpio-count is unspecified

Additionally, drop the bank-name property as it isn't used in upstream,
and we can just hardcode the bank name instead.

Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 drivers/gpio/qcom_pmic_gpio.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 7b83c67fa464..5221bd27825e 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -245,14 +245,39 @@ static int qcom_gpio_probe(struct udevice *dev)
return 0;
 }
 
+/*
+ * Parse basic GPIO count specified via the gpio-ranges property
+ * as specified in Linux devicetrees
+ * Returns < 0 on error, otherwise gpio count
+ */
+static int qcom_gpio_of_parse_ranges(struct udevice *dev)
+{
+   int ret;
+   struct ofnode_phandle_args args;
+
+   ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "gpio-ranges",
+NULL, 3, 0, );
+   if (ret)
+   return log_msg_ret("gpio-ranges", ret);
+
+   return args.args[2];
+}
+
 static int qcom_gpio_of_to_plat(struct udevice *dev)
 {
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int ret;
 
uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
-   uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
-   if (uc_priv->bank_name == NULL)
-   uc_priv->bank_name = "qcom_pmic";
+   if (!uc_priv->gpio_count) {
+   ret = qcom_gpio_of_parse_ranges(dev);
+   if (ret > 0)
+   uc_priv->gpio_count = ret;
+   else
+   return ret;
+   }
+
+   uc_priv->bank_name = "pmic";
 
return 0;
 }

-- 
2.42.1

[PATCH v6 4/9] gpio: qcom_pmic: drop pon GPIO driver

[Caleb Connolly]

Remove the (now unused) GPIO driver for the power and resin buttons on
the PMIC.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 drivers/gpio/Kconfig  |   5 +-
 drivers/gpio/qcom_pmic_gpio.c | 104 --
 2 files changed, 2 insertions(+), 107 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ba42b0768e12..e00b2f2fcfe3 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -309,12 +309,11 @@ config CMD_PCA953X
 config QCOM_PMIC_GPIO
bool "Qualcomm generic PMIC GPIO/keypad driver"
depends on DM_GPIO && PMIC_QCOM
+   select BUTTON
help
  Support for GPIO pins and power/reset buttons found on
  Qualcomm SoCs PMIC.
- Default name for GPIO bank is "pm8916".
- Power and reset buttons are placed in "pwkey_qcom" bank and
-  have gpio numbers 0 and 1 respectively.
+ The GPIO bank is called "pmic"
 
 config PCF8575_GPIO
bool "PCF8575 I2C GPIO Expander driver"
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index e5841f502953..7b83c67fa464 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -275,107 +275,3 @@ U_BOOT_DRIVER(qcom_pmic_gpio) = {
.priv_auto  = sizeof(struct qcom_gpio_bank),
 };
 
-
-/* Add pmic buttons as GPIO as well - there is no generic way for now */
-#define PON_INT_RT_STS0x10
-#define KPDPWR_ON_INT_BIT 0
-#define RESIN_ON_INT_BIT  1
-
-static int qcom_pwrkey_get_function(struct udevice *dev, unsigned offset)
-{
-   return GPIOF_INPUT;
-}
-
-static int qcom_pwrkey_get_value(struct udevice *dev, unsigned offset)
-{
-   struct qcom_gpio_bank *priv = dev_get_priv(dev);
-
-   int reg = pmic_reg_read(dev->parent, priv->pid + PON_INT_RT_STS);
-
-   if (reg < 0)
-   return 0;
-
-   switch (offset) {
-   case 0: /* Power button */
-   return (reg & BIT(KPDPWR_ON_INT_BIT)) != 0;
-   break;
-   case 1: /* Reset button */
-   default:
-   return (reg & BIT(RESIN_ON_INT_BIT)) != 0;
-   break;
-   }
-}
-
-/*
- * Since pmic buttons modelled as GPIO, we need empty direction functions
- * to trick u-boot button driver
- */
-static int qcom_pwrkey_direction_input(struct udevice *dev, unsigned int 
offset)
-{
-   return 0;
-}
-
-static int qcom_pwrkey_direction_output(struct udevice *dev, unsigned int 
offset, int value)
-{
-   return -EOPNOTSUPP;
-}
-
-static const struct dm_gpio_ops qcom_pwrkey_ops = {
-   .get_value  = qcom_pwrkey_get_value,
-   .get_function   = qcom_pwrkey_get_function,
-   .direction_input= qcom_pwrkey_direction_input,
-   .direction_output   = qcom_pwrkey_direction_output,
-};
-
-static int qcom_pwrkey_probe(struct udevice *dev)
-{
-   struct qcom_gpio_bank *priv = dev_get_priv(dev);
-   int reg;
-   u64 pid;
-
-   pid = dev_read_addr(dev);
-   if (pid == FDT_ADDR_T_NONE)
-   return log_msg_ret("bad address", -EINVAL);
-
-   priv->pid = pid;
-
-   /* Do a sanity check */
-   reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
-   if (reg != 0x1)
-   return log_msg_ret("bad type", -ENXIO);
-
-   reg = pmic_reg_read(dev->parent, priv->pid + REG_SUBTYPE);
-   if ((reg & 0x5) == 0)
-   return log_msg_ret("bad subtype", -ENXIO);
-
-   return 0;
-}
-
-static int qcom_pwrkey_of_to_plat(struct udevice *dev)
-{
-   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
-   uc_priv->gpio_count = 2;
-   uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
-   if (uc_priv->bank_name == NULL)
-   uc_priv->bank_name = "pwkey_qcom";
-
-   return 0;
-}
-
-static const struct udevice_id qcom_pwrkey_ids[] = {
-   { .compatible = "qcom,pm8916-pwrkey" },
-   { .compatible = "qcom,pm8994-pwrkey" },
-   { .compatible = "qcom,pm8998-pwrkey" },
-   { }
-};
-
-U_BOOT_DRIVER(pwrkey_qcom) = {
-   .name   = "pwrkey_qcom",
-   .id = UCLASS_GPIO,
-   .of_match = qcom_pwrkey_ids,
-   .of_to_plat = qcom_pwrkey_of_to_plat,
-   .probe  = qcom_pwrkey_probe,
-   .ops= _pwrkey_ops,
-   .priv_auto  = sizeof(struct qcom_gpio_bank),
-};

-- 
2.42.1

[PATCH v6 3/9] mach-snapdragon: switch to PMIC button driver

[Caleb Connolly]

The PMIC button driver is a much better representation of the hardware
here, adjust the boards to use upstream DT and the PMIC button driver
instead of exposing the buttons as GPIOs and relying on the GPIO-button
driver.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 arch/arm/dts/dragonboard410c-uboot.dtsi  | 11 --
 arch/arm/dts/dragonboard410c.dts | 22 +---
 arch/arm/dts/dragonboard820c-uboot.dtsi  | 12 ---
 arch/arm/dts/dragonboard820c.dts | 23 
 arch/arm/dts/dragonboard845c-uboot.dtsi  | 11 --
 arch/arm/dts/dragonboard845c.dts |  4 +++
 arch/arm/dts/sdm845.dtsi | 23 +---
 arch/arm/dts/starqltechn-uboot.dtsi  | 10 --
 arch/arm/dts/starqltechn.dts | 20 +++
 arch/arm/mach-snapdragon/Kconfig |  3 ++
 arch/arm/mach-snapdragon/init_sdm845.c   | 45 +---
 board/qualcomm/dragonboard410c/dragonboard410c.c | 31 ++--
 board/qualcomm/dragonboard820c/dragonboard820c.c | 29 +--
 13 files changed, 91 insertions(+), 153 deletions(-)

diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index 3b0bd0ed0a1b..cec64bf80f99 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -42,14 +42,3 @@
gpios = <_gpios 3 0>;
};
 };
-
-
-_pon {
-   key_vol_down {
-   gpios = <_pon 1 0>;
-   };
-
-   key_power {
-   gpios = <_pon 0 0>;
-   };
-};
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 9230dd3fd96c..c41fee977813 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -147,11 +147,23 @@
#address-cells = <0x1>;
#size-cells = <0x1>;
 
-   pm8916_pon: pm8916_pon@800 {
-   compatible = "qcom,pm8916-pwrkey";
-   reg = <0x800 0x96>;
-   #gpio-cells = <2>;
-   gpio-controller;
+   pon@800 {
+   compatible = "qcom,pm8916-pon";
+   reg = <0x800 0x100>;
+   mode-bootloader = <0x2>;
+   mode-recovery = <0x1>;
+
+   pwrkey {
+   compatible = 
"qcom,pm8941-pwrkey";
+   debounce = <15625>;
+   bias-pull-up;
+   };
+
+   pm8916_resin: resin {
+   compatible = 
"qcom,pm8941-resin";
+   debounce = <15625>;
+   bias-pull-up;
+   };
};
 
pm8916_gpios: pm8916_gpios@c000 {
diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi 
b/arch/arm/dts/dragonboard820c-uboot.dtsi
index 457728a43ecb..d93c7c1fbdee 100644
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
@@ -30,15 +30,3 @@
};
};
 };
-
-_pon {
-   key_vol_down {
-   gpios = <_pon 1 0>;
-   label = "key_vol_down";
-   };
-
-   key_power {
-   gpios = <_pon 0 0>;
-   label = "key_power";
-   };
-};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index ad201d48749c..0d9c9f7a4922 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -109,12 +109,23 @@
#address-cells = <0x1>;
#size-cells = <0x1>;
 
-   pm8994_pon: pm8994_pon@800 {
-   compatible = "qcom,pm8994-pwrkey";
-   reg = <0x800 0x96>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   gpio-bank-name="pm8994_key.";
+   pm8994_pon: pon@800 {
+   compatible = "qcom,pm8916-pon";
+   reg = <0x800 0x100>;
+   mode-bootloader = <0x2>;
+   mode-recovery = <0x1>;
+
+   pwrkey {
+ 

[PATCH v6 2/9] button: qcom-pmic: introduce Qualcomm PMIC button driver

[Caleb Connolly]

Qualcomm PMICs include a "pon" function which handles two buttons, the
power button and "resin" button (usually volume down). Introduce a new
driver following upstream Linux DT to enable these and map them to Enter
and Down respectively to enable use in boot menus.

Reviewed-by: Neil Armstrong 
Reviewed-by: Sumit Garg 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 MAINTAINERS   |   1 +
 drivers/button/Kconfig|   9 +++
 drivers/button/Makefile   |   1 +
 drivers/button/button-qcom-pmic.c | 165 ++
 4 files changed, 176 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f6d63c8ab563..8cd102eaa070 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -572,6 +572,7 @@ M:  Neil Armstrong 
 R: Sumit Garg 
 S: Maintained
 F: arch/arm/mach-snapdragon/
+F: drivers/button/button-qcom-pmic.c
 F: drivers/clk/qcom/
 F: drivers/gpio/msm_gpio.c
 F: drivers/mmc/msm_sdhci.c
diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 8ce2de37d62a..097b05f822e7 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -27,4 +27,13 @@ config BUTTON_GPIO
  The GPIO driver must used driver model. Buttons are configured using
  the device tree.
 
+config BUTTON_QCOM_PMIC
+   bool "Qualcomm power button"
+   depends on BUTTON
+   depends on PMIC_QCOM
+   help
+ Enable support for the power and "resin" (usually volume down) buttons
+ on Qualcomm SoCs. These will be configured as the Enter and Down keys
+ respectively, allowing navigation of bootmenu with buttons on device.
+
 endmenu
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index bbd18af14940..68555081a47a 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_BUTTON) += button-uclass.o
 obj-$(CONFIG_BUTTON_ADC) += button-adc.o
 obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
+obj-$(CONFIG_BUTTON_QCOM_PMIC) += button-qcom-pmic.o
\ No newline at end of file
diff --git a/drivers/button/button-qcom-pmic.c 
b/drivers/button/button-qcom-pmic.c
new file mode 100644
index ..34a976d1e6c6
--- /dev/null
+++ b/drivers/button/button-qcom-pmic.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm generic pmic gpio driver
+ *
+ * (C) Copyright 2015 Mateusz Kulikowski 
+ * (C) Copyright 2023 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_TYPE   0x4
+#define REG_SUBTYPE0x5
+
+struct qcom_pmic_btn_priv {
+   u32 base;
+   u32 status_bit;
+   int code;
+   struct udevice *pmic;
+};
+
+#define PON_INT_RT_STS0x10
+#define KPDPWR_ON_INT_BIT 0
+#define RESIN_ON_INT_BIT  1
+
+#define NODE_IS_PWRKEY(node) (!strncmp(ofnode_get_name(node), "pwrkey", 
strlen("pwrkey")))
+#define NODE_IS_RESIN(node) (!strncmp(ofnode_get_name(node), "resin", 
strlen("resin")))
+
+static enum button_state_t qcom_pwrkey_get_state(struct udevice *dev)
+{
+   struct qcom_pmic_btn_priv *priv = dev_get_priv(dev);
+
+   int reg = pmic_reg_read(priv->pmic, priv->base + PON_INT_RT_STS);
+
+   if (reg < 0)
+   return 0;
+
+   return (reg & BIT(priv->status_bit)) != 0;
+}
+
+static int qcom_pwrkey_get_code(struct udevice *dev)
+{
+   struct qcom_pmic_btn_priv *priv = dev_get_priv(dev);
+
+   return priv->code;
+}
+
+static int qcom_pwrkey_probe(struct udevice *dev)
+{
+   struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+   struct qcom_pmic_btn_priv *priv = dev_get_priv(dev);
+   ofnode node = dev_ofnode(dev);
+   int ret;
+   u64 base;
+
+   /* Ignore the top-level pon node */
+   if (!uc_plat->label)
+   return 0;
+
+   /* the pwrkey and resin nodes are children of the "pon" node, get the
+* PMIC device to use in pmic_reg_* calls.
+*/
+   priv->pmic = dev->parent->parent;
+
+   /* Get the address of the parent pon node */
+   base = dev_read_addr(dev->parent);
+   if (base == FDT_ADDR_T_NONE) {
+   printf("%s: Can't find address\n", dev->name);
+   return -EINVAL;
+   }
+
+   priv->base = base;
+
+   /* Do a sanity check */
+   ret = pmic_reg_read(priv->pmic, priv->base + REG_TYPE);
+   if (ret != 0x1 && ret != 0xb) {
+   printf("%s: unexpected PMIC function type %d\n", dev->name, 
ret);
+   return -ENXIO;
+   }
+
+   ret = pmic_reg_read(priv->pmic, priv->base + REG_SUBTYPE);
+   if ((ret & 0x7) == 0) {
+   printf("%s: unexpected PMCI function subtype %d\n", dev->name, 
ret);
+   return -ENXIO;
+   }
+
+   if (NODE_IS_PWRKEY(node)) {
+   priv->status_bit = 0;
+   priv->code = KEY_ENTER;
+   } else if 

[PATCH v6 1/9] gpio: qcom_pmic: fix silent dev_read_addr downcast

[Caleb Connolly]

priv->pid is uint32_t, but dev_read_addr() returns a uint64_t on arm64,
with the upper bits being used for error codes. Do error checking before
downcasting to u32 to prevent errors being silently ignored.

Reviewed-by: Sumit Garg 
Reviewed-by: Neil Armstrong 
Tested-by: Sumit Garg 
Signed-off-by: Caleb Connolly 
---
 drivers/gpio/qcom_pmic_gpio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 65feb453ebc3..e5841f502953 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -221,11 +221,14 @@ static int qcom_gpio_probe(struct udevice *dev)
 {
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+   u64 pid;
 
-   priv->pid = dev_read_addr(dev);
-   if (priv->pid == FDT_ADDR_T_NONE)
+   pid = dev_read_addr(dev);
+   if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
 
+   priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != REG_TYPE_VAL)
@@ -328,11 +331,14 @@ static int qcom_pwrkey_probe(struct udevice *dev)
 {
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+   u64 pid;
 
-   priv->pid = dev_read_addr(dev);
-   if (priv->pid == FDT_ADDR_T_NONE)
+   pid = dev_read_addr(dev);
+   if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
 
+   priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != 0x1)

-- 
2.42.1

[PATCH v6 0/9] Qualcomm PMIC fixes

[Caleb Connolly]

This series addresses some long-standing issues with the SPMI arb
driver, the PMIC, and the PMIC GPIO. It fixes compatibility with
upstream Linux devicetrees, and simplifies pwrkey/resin support by
rewriting the pon driver to be a button driver rather than a GPIO
driver.

Existing users are adjusted to use the new button driver in their
oard init code.

This series is based on the pinctrl [1] and clock [2] cleanup series.
There may be some DTS conflicts applying it standalone.

[1]: 
https://lore.kernel.org/u-boot/20231106-b4-qcom-pinctrl-v2-0-406e8d868...@linaro.org/
[2]: 
https://lore.kernel.org/u-boot/20231103-b4-qcom-clk-v3-0-8d2d460ec...@linaro.org/

---
Changes in v6:
- Drop spurious change to qcom_pmic_gpio udevice_id table that was left
  in by mistake
- Drop bank-name property from qcs404-evb.dts that was missed previously
- Link to v5: 
https://lore.kernel.org/r/20231130-b4-qcom-dt-compat-v5-0-41500e237...@linaro.org

Changes in v5:
- Split "rework pwrkey driver into a button driver" into multiple
  commits
- Split "qcom_pmic: fix support for upstream DT" into multiple commits
- Link to v4: 
https://lore.kernel.org/r/20231128-b4-qcom-dt-compat-v4-0-949d0982d...@linaro.org

Changes in v4:
* Remove some now unsupported DT binding docs
* Fix qcs404 SPMI arb dts
* Link to v3: 
https://lore.kernel.org/r/20231114-b4-qcom-dt-compat-v3-0-88a92f8f0...@linaro.org

Changes in v3:
* Remove now-unneeded header includes in dragonboard{410,820}c-uboot.dtsi
* Drop non-standard DTS support from PMIC GPIO driver
* Also remove old gpio-keys nodes from starqltechn-uboot.dtsi
* Link to v2: 
https://lore.kernel.org/r/20231108-b4-qcom-dt-compat-v2-0-713233c72...@linaro.org

Changes in v2:
* Avoid using non-standard "label" and "linux,code" properties for
  buttons
* Add missing sdm845 DTS parts
* Put button driver in drivers/button
* Link to v1: 
https://lore.kernel.org/r/20231106-b4-qcom-dt-compat-v1-0-0ccbb7841...@linaro.org

---
Caleb Connolly (9):
  gpio: qcom_pmic: fix silent dev_read_addr downcast
  button: qcom-pmic: introduce Qualcomm PMIC button driver
  mach-snapdragon: switch to PMIC button driver
  gpio: qcom_pmic: drop pon GPIO driver
  gpio: qcom_pmic: support upstream DT
  dts: qcom: adjust pmic gpio to use upstream bindings
  gpio: qcom_pmic: drop gpio-count property
  spmi: msm: fix register range names
  pmic: qcom: dont use dev_read_addr to get USID

 MAINTAINERS  |   1 +
 arch/arm/dts/dragonboard410c-uboot.dtsi  |  11 --
 arch/arm/dts/dragonboard410c.dts |  25 +++-
 arch/arm/dts/dragonboard820c-uboot.dtsi  |  12 --
 arch/arm/dts/dragonboard820c.dts |  26 ++--
 arch/arm/dts/dragonboard845c-uboot.dtsi  |  11 --
 arch/arm/dts/dragonboard845c.dts |   4 +
 arch/arm/dts/qcs404-evb.dts  |  10 +-
 arch/arm/dts/sdm845.dtsi |  28 ++--
 arch/arm/dts/starqltechn-uboot.dtsi  |  10 --
 arch/arm/dts/starqltechn.dts |  20 +--
 arch/arm/mach-snapdragon/Kconfig |   3 +
 arch/arm/mach-snapdragon/init_sdm845.c   |  45 ++-
 board/qualcomm/dragonboard410c/dragonboard410c.c |  31 ++---
 board/qualcomm/dragonboard820c/dragonboard820c.c |  29 ++--
 doc/device-tree-bindings/gpio/pm8916_gpio.txt|  48 ---
 doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt |  94 -
 doc/device-tree-bindings/spmi/spmi-msm.txt   |  26 
 drivers/button/Kconfig   |   9 ++
 drivers/button/Makefile  |   1 +
 drivers/button/button-qcom-pmic.c| 165 +++
 drivers/gpio/Kconfig |   5 +-
 drivers/gpio/qcom_pmic_gpio.c| 138 +--
 drivers/power/pmic/pmic_qcom.c   |  13 +-
 drivers/spmi/spmi-msm.c  |  46 +++
 25 files changed, 337 insertions(+), 474 deletions(-)
---
base-commit: 11b868d152760a49895e051c285926a0461abcef

// Caleb (they/them)

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Maxim Uvarov]

I think I solved the size issue on all the boards.

Key changes:
1. remove compilation of original ping.c and tftp.c (tftp had also server
code, so I will partially bring it back.)
2. LTO=y
3. CONFIG_LOGLEVEL=3 instead of 4.
4. CONFIG_CMD_DATE is not set
5. CONFIG_CMD_LICENSE is not set
6. CONFIG_CMD_PING (if 1-6 did not help).

And these changes were enough for CI tagrets to build.
I also tested that Raspberry PI 4B works fine (dhcp, ping). Looking for
other boards to test.

For example for this tbs2910 board changes are:

--- a/configs/tbs2910_defconfig
+++ b/configs/tbs2910_defconfig
@@ -18,6 +18,7 @@ CONFIG_SYS_MEMTEST_END=0x2f40
 CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
 CONFIG_BOARD_SIZE_LIMIT=392192
+CONFIG_TIMESTAMP=y (this was added by savedefconfig)
 # CONFIG_BOOTSTD is not set
 CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOOTDELAY=3
@@ -26,6 +27,7 @@ CONFIG_BOOTCOMMAND="mmc rescan; if run bootcmd_up1; then
run bootcmd_up2; else r
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start"
 CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb"
+CONFIG_LOGLEVEL=3
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Matrix U-Boot> "
@@ -52,7 +54,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
-CONFIG_CMD_TIME=y
+# CONFIG_CMD_DATE is not set
 CONFIG_CMD_SYSBOOT=y
 # CONFIG_CMD_VIDCONSOLE is not set
 CONFIG_CMD_EXT2=y

BR,
Maxim.


On Tue, 28 Nov 2023 at 13:09, Maxim Uvarov  wrote:

>
>
> On Tue, 28 Nov 2023 at 03:20, Soeren Moch  wrote:
>
>> On 27.11.23 14:11, Tom Rini wrote:
>> > On Mon, Nov 27, 2023 at 06:57:09PM +0600, Maxim Uvarov wrote:
>> >
>> >> Increase allowed binary size to fit lwip code.
>> >>
>> >> Signed-off-by: Maxim Uvarov 
>> >> ---
>> >>   configs/tbs2910_defconfig | 2 +-
>> >>   1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
>> >> index 8fbe84f1d2..ce40efa9ab 100644
>> >> --- a/configs/tbs2910_defconfig
>> >> +++ b/configs/tbs2910_defconfig
>> >> @@ -17,7 +17,7 @@ CONFIG_SYS_MEMTEST_START=0x1000
>> >>   CONFIG_SYS_MEMTEST_END=0x2f40
>> >>   CONFIG_LTO=y
>> >>   CONFIG_HAS_BOARD_SIZE_LIMIT=y
>> >> -CONFIG_BOARD_SIZE_LIMIT=392192
>> >> +CONFIG_BOARD_SIZE_LIMIT=417792
>> >>   # CONFIG_BOOTSTD is not set
>> >>   CONFIG_SUPPORT_RAW_INITRD=y
>> >>   CONFIG_BOOTDELAY=3
>> > This is another case where the binary size is a fairly hard limit. You
>> > forgot to cc the board maintainer here (and I assume the rest of the
>> > series too) for these config changes.
>> ThanksTom for sending a notification to me.
>>
>> Yes, the CONFIG_BOARD_SIZE_LIMIT is a hard limit and this patch in its
>> current form will break tbs2910 support and even brick the board for
>> some configurations. So NAK for this patch.
>> > I think on this platform it's not
>> > impossible (like it is on am335x where I just replied) but really
>> > difficult. I'll let Soeren comment on if switching the network stack to
>> > lwip is the kind of feature enhancement that warrants the pain of
>> > dealing with the size change here or not.
>> Network boot is no important feature for this board and not used in
>> the default boot configuration. But network support always was part
>> of the config, may be used by some users, and is at least required
>> to communicate the ethernet address to linux.
>>
>> So I'm not interested in a new network stack for this board, but
>> also cannot disable network support completely. This seems to be a
>> problem for this patch series, since networking support implies LWIP
>> now.
>>
>>
> Thanks Soeren for the explanation. Then yes, something more advanced is
> needed
> to be done here.
>
>
>
>> The question for me is, why is the new network stack consuming so
>> much space, with only a few enabled commands? Is the whole library
>> linked in with some unused features (the cover letter mentions much
>> more than what seems to be used in the converted commands). Or is
>> the old network stack linked in in parallel to the new one? Can
>> we save space here?
>>
>
> Yes, the old code is still there. I decided to not touch it for the first
> integration (arp.o, bootp.o, ping.o and
> mostly all from net/Makefile).  Those files also have reference code in
> net/net.c. Not compiling
> and not linking this code will save some space, but It's larger than the
> current version.
> Like for EVM SPL code with usb+net+ext4 and etc have very minimal space
> for network stack.
> I will take a look at this more closely...
>
>
>>
>> NFS support in the old networking code is quite big, enabled by default,
>> and probably still there in parallel to this new lwip library. If there
>> is really no other option to save space, and lwip in general is agreed
>> to be the way forward for U-Boot, and only tbs2910 is blocking that,
>> then from my point of view disabling NFS for tbs2910 could be a way
>> to stay within the size limit.
>>
>> ok. I think that by default we need something very 

Re: [PATCH 00/21] Qualcomm generic board support

[Daniel Thompson]

On Tue, Dec 05, 2023 at 10:36:28AM +, ff wrote:
> > Le 5 déc. 2023 à 10:46, Sumit Garg  a écrit :
> >
> > + U-boot custodians list
> >
> >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
> >>  wrote:
> >>
> >> On 05/12/2023 08:13, Sumit Garg wrote:
> > @DT bindings maintainers,
> >
> > Given the ease of maintenance of DT bindings within Linux kernel
> > source tree, I don't have a specific objection there. But can we
> > ease DTS testing for firmware/bootloader projects by providing a
> > versioned release package for DT bindings? Or if someone else
> > has a better idea here please feel free to chime in.
> 
>  This doesn't work for you?:
> 
>  https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> >>>
> >>> Thanks, this is certainly a good step which I wasn't aware of.
> >>> Further simplification can be done to decouple devicetree source
> >>> files from DT bindings.
> >>
> >> Why?
> >
> > I suppose you are already aware that Linux DTS files are a subset of
> > what could be supported by devicetree schemas. There can be
> > firmware/bootloader specific properties (one example being [1])
> > which Linux kernel can simply ignore. Will you be willing to add all
> > of those DT properties to Linux DTS files and maintain them?
>
> A pre-existing effort to solve the same problem as [1] is System
> Device Tree, discussed in the context of Linaro supported OpenAMP
> project. It is not just about cherry picking devices that have
> bindings in Linux but also information about clock and power domains
> or devices that are not seen by Linux.  It is obvious that the
> resulting bindings should be maintained upstream in the DT repo
> regardless of the communities adopted solution.

This seems to be artificially linking two topics: system DT and DT
schema validation within u-boot. They are somewhat related but one of
not a precondition of the other.


> > However, DT bindings are something which should be common, the
> > hardware description of a device should be universal. IMO, splitting
> > DT bindings alone would ease the compliance process for u-boot
> > drivers in quite similar manner to Linux drivers.
>
> I remember a discussion with ST on that topic related to Framebuffer.
> U-Boot can need a very different representation of the same device to
> use it while Linux need an in-depth description of all shaders and «
> stuff » (another reason why [1] is addressing only a portion of the
> problem) So even if there is a single frame buffer binding, there
> should be two (at least) conformance tests.

I don't follow this, for two reasons.

1. DT describes the hardware, not how it is driven. Having a relationship
   between u-boot and linux DTs with different representation would
   imply that the hardware changes between u-boot and the kernel.

2. Even if we were to accept that there must be two device tree instances
   (beyond transient workarounds for missing features), why would there
   need to be two conformance tests rather than one conformance test run
   on the two DTs?


Daniel.

Re: [PATCH 00/21] Qualcomm generic board support

[ff]

> Le 5 déc. 2023 à 10:46, Sumit Garg  a écrit :
> 
> + U-boot custodians list
> 
>> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
>>  wrote:
>> 
>> On 05/12/2023 08:13, Sumit Garg wrote:
> @DT bindings maintainers,
> 
> Given the ease of maintenance of DT bindings within Linux kernel
> source tree, I don't have a specific objection there. But can we ease
> DTS testing for firmware/bootloader projects by providing a versioned
> release package for DT bindings? Or if someone else has a better idea
> here please feel free to chime in.
 
 This doesn't work for you?:
 
 https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
>>> 
>>> Thanks, this is certainly a good step which I wasn't aware of. Further
>>> simplification can be done to decouple devicetree source files from DT
>>> bindings.
>> 
>> Why?
> 
> I suppose you are already aware that Linux DTS files are a subset of
> what could be supported by devicetree schemas. There can be
> firmware/bootloader specific properties (one example being [1]) which
> Linux kernel can simply ignore. Will you be willing to add all of
> those DT properties to Linux DTS files and maintain them?
> 
A pre-existing effort to solve the same problem as [1] is System Device Tree, 
discussed in the context of Linaro supported OpenAMP project. It is not just 
about cherry picking devices that have bindings in Linux but also information 
about clock and power domains or devices that are not seen by Linux.
It is obvious that the resulting bindings should be maintained upstream in the 
DT repo regardless of the communities adopted solution.

> However, DT bindings are something which should be common, the
> hardware description of a device should be universal. IMO, splitting
> DT bindings alone would ease the compliance process for u-boot drivers
> in quite similar manner to Linux drivers.
> 
I remember a discussion with ST on that topic related to Framebuffer. U-Boot 
can need a very different representation of the same device to use it while 
Linux need an in-depth description of all shaders and « stuff » (another reason 
why [1] is addressing only a portion of the problem)
So even if there is a single frame buffer binding, there should be two (at 
least) conformance tests.

> [1] 
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml
> 
>> 
>>> AFAIK, DT bindings should be forwards and backwards
>>> compatible.
>> 
>> The same with DTS.
>> 
>>> So if you pick up DTS or DTB from any project tree
>>> (upstream kernel or stable kernel or u-boot) then DT schema validation
>>> would ensure that corresponding DTS or DTB doesn't regress the DT
>>> bindings.
>> 
>> And why is this argument to decouple DTS from bindings?
>> 
> 
> See above.
> 
>>> 
>>> Ideally, it should be more user/CI friendly if DT bindings can be
>>> easily installed alongside devicetree schema tools [1].
>>> 
>>> [1] https://github.com/devicetree-org/dt-schema
>> 
>> Does it mean you will work on this?
> 
> I am happy to collaboratively work with DT bindings maintainers and
> the u-boot community once we can reach a consensus on the above.
> Basically the main motive here is to validate DTS files present in the
> u-boot tree and be able to reliably pass them to whichever Linux
> kernel version you are trying to boot. IOW, make Linux distros to
> reliably boot with devicetree supplied by u-boot.
> 
> -Sumit
> 
>> 
>> Best regards,
>> Krzysztof
>> 
> ___
> boot-architecture mailing list -- boot-architect...@lists.linaro.org
> To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: [PATCH v4 2/8] arm: mach-k3: common: Reserve video memory from end of the RAM

[Nikhil Jain]

Hi Devarsh,

On 25/11/23 21:56, Devarsh Thakkar wrote:
> Setup video memory before page table reservation using
> "spl_reserve_video_from_ram_top" which ensures framebuffer memory gets
> reserved from the end of RAM.
>
> This is done to enable the next stage to directly skip the
> pre-reserved area from previous stage right from the end of RAM without
> having to make any gaps/holes to accommodate those regions which was the
> case before as previous stage reserved region not from the end of RAM.
>
> Use gd->ram_top instead of local ram_top and update gd->reloc_addr after
> each reservation to ensure further regions are reserved properly.
>
> Signed-off-by: Devarsh Thakkar 

Reviewed-by: Nikhil M Jain 

Regards,
Nikhil
> ---
> V2:
>  - Make a generic function "spl_reserve_video" under
>common/spl which can be re-used by other platforms too
>for reserving video memory from spl.
>
> V3:
>  - Change spl_reserve_video to spl_reserve_video_from_ram_top
>which enforce framebuffer reservation from end of RAM
>  - Use gd->ram_top instead of local ram_top and update
>gd->reloc_addr after each reservation
>  - Print error message on framebuffer reservation
>
> V4:
>  - Split this into a separate patch
> ---
>  arch/arm/mach-k3/common.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index fd400e7e3d..42ceeb5296 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -524,19 +524,26 @@ void remove_fwl_configs(struct fwl_data *fwl_data, 
> size_t fwl_data_size)
>  void spl_enable_cache(void)
>  {
>  #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
> - phys_addr_t ram_top = CFG_SYS_SDRAM_BASE;
> + gd->ram_top = CFG_SYS_SDRAM_BASE;
> + int ret = 0;
>  
>   dram_init();
>  
>   /* reserve TLB table */
>   gd->arch.tlb_size = PGTABLE_SIZE;
>  
> - ram_top += get_effective_memsize();
> + gd->ram_top += get_effective_memsize();
>   /* keep ram_top in the 32-bit address space */
> - if (ram_top >= 0x1)
> - ram_top = (phys_addr_t) 0x1;
> + if (gd->ram_top >= 0x1)
> + gd->ram_top = (phys_addr_t)0x1;
>  
> - gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
> + gd->relocaddr = gd->ram_top;
> +
> + ret = spl_reserve_video_from_ram_top();
> + if (ret)
> + panic("Failed to reserve framebuffer memory (%d)\n", ret);
> +
> + gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
>   gd->arch.tlb_addr &= ~(0x1 - 1);
>   debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
> gd->arch.tlb_addr + gd->arch.tlb_size);

[PATCH v2] test/py: mii: Add tests for mii command

[Love Kumar]

Add below test cases for mii commands:
mii_info -To display MII PHY info
mii_list - To list MII devices
mii_set_device - To set MII device
mii_read - To reads register from MII PHY address
mii_dump - To display data from MII PHY address

Signed-off-by: Love Kumar 
---
Changes in v2:
  - Get MII device list from env instead of auto-detecting it
  - Set the MII device to its current device after testing so that it
  won't impact next cases
---
 test/py/tests/test_mii.py | 92 +++
 1 file changed, 92 insertions(+)
 create mode 100644 test/py/tests/test_mii.py

diff --git a/test/py/tests/test_mii.py b/test/py/tests/test_mii.py
new file mode 100644
index ..e9bdbadffc8e
--- /dev/null
+++ b/test/py/tests/test_mii.py
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import re
+
+"""
+Note: This test doesn't rely on boardenv_* configuration value but they can
+change test behavior.
+
+For example:
+
+# Setup env__mii_deive_test_skip to True if tests with ethernet PHY devices
+# should be skipped. For example: Missing PHY device
+env__mii_device_test_skip = True
+
+# Setup env__mii_device_test to set the MII device names. Test will be skipped
+# if env_mii_device_test is not set
+env__mii_device_test = {
+"device_list": ["eth0", "eth1"],
+}
+"""
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_info(u_boot_console):
+if u_boot_console.config.env.get("env__mii_device_test_skip", False):
+pytest.skip("MII device test is not enabled!")
+expected_output = "PHY"
+output = u_boot_console.run_command("mii info")
+if not re.search(r"PHY (.+?):", output):
+pytest.skip("PHY device does not exist!")
+assert expected_output in output
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_list(u_boot_console):
+if u_boot_console.config.env.get("env__mii_device_test_skip", False):
+pytest.skip("MII device test is not enabled!")
+
+f = u_boot_console.config.env.get("env__mii_device_test", None)
+if not f:
+pytest.skip("No MII device to test!")
+
+dev_list = f.get("device_list")
+if len(dev_list) == 0:
+pytest.fail("No MII device list provided via env__mii_device_test!")
+
+expected_output = "Current device"
+output = u_boot_console.run_command("mii device")
+mii_devices = (
+re.search(r"MII devices: '(.+)'", output).groups()[0].replace("'", 
"").split()
+)
+
+assert len([x for x in dev_list if x in mii_devices]) == len(dev_list)
+assert expected_output in output
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_set_device(u_boot_console):
+test_mii_list(u_boot_console)
+f = u_boot_console.config.env.get("env__mii_device_test", None)
+dev_list = f.get("device_list")
+output = u_boot_console.run_command("mii device")
+current_dev = re.search(r"Current device: '(.+?)'", output).groups()[0]
+
+for dev in dev_list:
+u_boot_console.run_command(f"mii device {dev}")
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
+
+u_boot_console.run_command(f"mii device {current_dev}")
+output = u_boot_console.run_command("mii device")
+dev = re.search(r"Current device: '(.+?)'", output).groups()[0]
+assert current_dev == dev
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_read(u_boot_console):
+test_mii_list(u_boot_console)
+output = u_boot_console.run_command("mii info")
+eth_addr = hex(int(re.search(r"PHY (.+?):", output).groups()[0], 16))
+u_boot_console.run_command(f"mii read {eth_addr} 0")
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_dump(u_boot_console):
+test_mii_list(u_boot_console)
+expected_response = "PHY control register"
+output = u_boot_console.run_command("mii info")
+eth_addr = hex(int(re.search(r"PHY (.+?):", output).groups()[0], 16))
+response = u_boot_console.run_command(f"mii dump {eth_addr} 0")
+assert expected_response in response
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
-- 
2.25.1

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Ahmad Fatoum]

Hello Simon,

On 02.12.23 04:54, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
> 
> The files compress from about 86MB to 24MB using this approach.
> 
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
> 
> Add a 'make image.fit' build target for arm64, as well. Use
> FIT_COMPRESSION to select a different algorithm.
> 
> The FIT can be examined using 'dumpimage -l'.
> 
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
> 
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
> 
> Signed-off-by: Simon Glass 

kernel_noload support is now in barebox next branch and I tested this
series against it:

Tested-by: Ahmad Fatoum  # barebox

> +"""Build a FIT containing a lot of devicetree files
> +
> +Usage:
> +make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> +-f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> +/tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> +
> +Creates a FIT containing the supplied kernel and a directory containing the
> +devicetree files.
> +
> +Use -E to generate an external FIT (where the data is placed after the
> +FIT data structure). This allows parsing of the data without loading
> +the entire FIT.
> +
> +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> +zstd algorithms.
> +
> +The resulting FIT can be booted by bootloaders which support FIT, such
> +as U-Boot, Linuxboot, Tianocore, etc.

Feel free to add barebox to the list. Did you check whether Linuxboot and
Tianocore support kernel_noload?

> +fsw.property_u32('load', 0)
> +fsw.property_u32('entry', 0)

I still think load and entry dummy values are confusing and should be dropped.

> +with fsw.add_node(f'fdt-{seq}'):
> +# Get the compatible / model information
> +with open(fname, 'rb') as inf:
> +data = inf.read()
> +fdt = libfdt.FdtRo(data)
> +model = fdt.getprop(0, 'model').as_str()
> +compat = fdt.getprop(0, 'compatible')
> +
> +fsw.property_string('description', model)
> +fsw.property_string('type', 'flat_dt')
> +fsw.property_string('arch', arch)
> +fsw.property_string('compression', compress)
> +fsw.property('compatible', bytes(compat))
> +
> +with open(fname, 'rb') as inf:
> +compressed = compress_data(inf, compress)
> +fsw.property('data', compressed)
> +return model, compat

After Doug's elaboration, extracting multiple compatibles is fine by me.

Cheers,
Ahmad

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 1/6] arm: mach-k3: common: Reserve video memory from end of the RAM

[Nikhil Jain]

Hi Devarsh,

On 10/11/23 20:59, Devarsh Thakkar wrote:
> Add function spl_reserve_video which is a wrapper
> around video_reserve to setup video memory and update
> the relocation address pointer.
>
> Setup video memory before page table reservation so that
> framebuffer memory gets reserved from the end of RAM.
>
> This is as per the new policy being discussed for passing
> blobs where each of the reserved areas for bloblists
> to be passed need to be reserved at the end of RAM.
>
> This is done to enable the next stage to directly skip
> the pre-reserved area from previous stage right from the end of RAM
> without having to make any gaps/holes to accommodate those
> regions which was the case before as previous stage
> reserved region not from the end of RAM.
>
> Suggested-by: Simon Glass 
> Signed-off-by: Devarsh Thakkar 

Reviewed-By: Nikhil M Jain 

Regards,
Nikhil
> ---
> V2:
> - Make a generic function "spl_reserve_video" under
>   common/spl which can be re-used by other platforms too
>   for reserving video memory from spl.
>
> V3:
> - Change spl_reserve_video to spl_reserve_video_from_ram_top
>   which enforce framebuffer reservation from end of RAM
> - Use gd->ram_top instead of local ram_top and update
>   gd->reloc_addr after each reservation
> - Print error message on framebuffer reservation
> ---
>  arch/arm/mach-k3/common.c | 17 -
>  common/spl/spl.c  | 27 +++
>  include/spl.h |  6 ++
>  3 files changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index c3006ba387..6590045140 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -525,19 +525,26 @@ void remove_fwl_configs(struct fwl_data *fwl_data, 
> size_t fwl_data_size)
>  void spl_enable_dcache(void)
>  {
>  #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
> - phys_addr_t ram_top = CFG_SYS_SDRAM_BASE;
> + gd->ram_top = CFG_SYS_SDRAM_BASE;
> + int ret = 0;
>  
>   dram_init();
>  
>   /* reserve TLB table */
>   gd->arch.tlb_size = PGTABLE_SIZE;
>  
> - ram_top += get_effective_memsize();
> + gd->ram_top += get_effective_memsize();
>   /* keep ram_top in the 32-bit address space */
> - if (ram_top >= 0x1)
> - ram_top = (phys_addr_t) 0x1;
> + if (gd->ram_top >= 0x1)
> + gd->ram_top = (phys_addr_t)0x1;
>  
> - gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
> + gd->relocaddr = gd->ram_top;
> +
> + ret = spl_reserve_video_from_ram_top();
> + if (ret)
> + pr_err("ERROR: Failed to framebuffer memory in SPL\n");
> +
> + gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
>   gd->arch.tlb_addr &= ~(0x1 - 1);
>   debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
> gd->arch.tlb_addr + gd->arch.tlb_size);
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 732d90d39e..452bf303de 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  DECLARE_BINMAN_MAGIC_SYM;
> @@ -151,6 +152,32 @@ void spl_fixup_fdt(void *fdt_blob)
>  #endif
>  }
>  
> +/*
> + * Reserve video memory for SPL splash screen from
> + * end of RAM
> + *
> + * RETURN
> + * 0 : On success
> + * Non-zero : On failure
> + */
> +int spl_reserve_video_from_ram_top(void)
> +{
> + if (CONFIG_IS_ENABLED(VIDEO)) {
> + ulong addr;
> + int ret;
> +
> + addr = gd->ram_top;
> + ret = video_reserve();
> + if (ret)
> + return ret;
> + debug("Reserving %luk for video at: %08lx\n",
> +   ((unsigned long)gd->relocaddr - addr) >> 10, addr);
> + gd->relocaddr = addr;
> + }
> +
> + return 0;
> +}
> +
>  ulong spl_get_image_pos(void)
>  {
>   if (!CONFIG_IS_ENABLED(BINMAN_UBOOT_SYMBOLS))
> diff --git a/include/spl.h b/include/spl.h
> index 0d49e4a454..39f2a7581d 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -825,6 +825,12 @@ int spl_usb_load(struct spl_image_info *spl_image,
>  
>  int spl_ymodem_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev);
> +/**
> + * spl_reserve_video_from_ram_top() - Reserve framebuffer memory from end of 
> RAM
> + *
> + * Return: 0 on success, otherwise error code
> + */
> +int spl_reserve_video_from_ram_top(void);
>  
>  /**
>   * spl_invoke_atf - boot using an ARM trusted firmware image

Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree

[Ahmad Fatoum]

Hello,

On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37 AM Simon 
Glass  wrote:
>> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum  wrote:
>>> On 30.11.23 21:30, Simon Glass wrote:
 On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum  wrote:
> On 29.11.23 20:44, Simon Glass wrote:
 I don't have an example to hand, but this is the required mechanism of
 FIT. This feature has been in place for many years and is used by
 ChromeOS, at least.
>>>
>>> I see the utility of a FIT configuration with
>>>
>>> compatible = "vendor,board-rev-a", "vendor,board-rev-b";
>>>
>>> I fail to see a utility for a configuration with
>>>
>>> compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
>>>
>>> Any configuration that ends up being booted because "vendor,SoC" was 
>>> matched is
>>> most likely doomed to fail. Therefore, I would suggest that only the top 
>>> level
>>> configuration is written into the FIT configurations automatically.
>>
>> Firstly, I am not an expert on this.
>>
>> Say you have a board with variants. The compatible string in U-Boot
>> may be something like:
>>
>> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>>
>> If you then have several FIT configurations, they may be something like:
>>
>> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>>
>> You want to choose the second one, since it is a better match than the 
>> others.

Now imagine, you are building a kernel that has no DT support for the Veyron,
but instead has support for the Phytec RK3288 PCM-947:

  phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288

As far as I understand U-Boot code, A veyron U-Boot would boot the Phytec DT
if CONFIG_FIT_BEST_MATCH is set, although it's a bad match and a boot failure
should rather have occurred.

>> +Doug Anderson who knows a lot more about this than me.
> 
> Hopefully this is all explained by:
> 
> https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html

Thanks Doug, this was helpful. The missing information to me was that
depthcharge only compares the top-level board compatible in addition
to runtime generated board compatibles, unlike what U-Boot seems to do.

barebox only compares its top-level compatible against the FIT configuration
compatibles, so adding a full compatible list to the configuration nodes as done
by this series should be ok there as well. I think U-Boot could run into
issues though as described above.

Out of curiosity: I only heard about Depthcharge before as exploitation toolkit
for U-Boot. Can you point me at some documentation on what the Depthcharge 
bootloader
does what U-Boot (which was presumably used before?) doesn't?

Thanks,
Ahmad

> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v4 0/4] bootflow: bootmeth_efi: Fix network efi boot.

[Shantur Rathore]

Hi Simon,

On Tue, Dec 5, 2023 at 12:52 AM Simon Glass  wrote:
>
> Hi Shantur,
>
> On Mon, 4 Dec 2023 at 05:38, Shantur Rathore  wrote:
> >
> > Hi Simon,
> >
> > On Sun, Nov 19, 2023 at 4:56 PM Shantur Rathore  wrote:
> > >
> > >
> > > Currently bootmeth_efi crashes while doing a network (dhcp) boot.
> > > This patch series fixes issues and both network and disk boot works.
> > >
> > How can I help to get this patch series merged in?
>
> You can check patchwork [1] to see who it is assigned to. I don't see
> it in my queue though.
>
It's with Tom Rini I believe but with status Needs Review / ACK.

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

Kind Regards,
Shantur

[PATCH] riscv: sifive: unmatched: migrate to text environment

[Yong-Xuan Wang]

Migrate to the new environment format and drop most of the config.h.

Signed-off-by: Yong-Xuan Wang 
---
 board/sifive/unmatched/unmatched.env | 19 ++
 configs/sifive_unmatched_defconfig   |  2 +-
 include/configs/sifive-unmatched.h   | 37 
 3 files changed, 20 insertions(+), 38 deletions(-)
 create mode 100644 board/sifive/unmatched/unmatched.env

diff --git a/board/sifive/unmatched/unmatched.env 
b/board/sifive/unmatched/unmatched.env
new file mode 100644
index 00..0f1e5a7174
--- /dev/null
+++ b/board/sifive/unmatched/unmatched.env
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+/* environment for HiFive Unmatched boards */
+
+kernel_addr_r=0x8020
+kernel_comp_addr_r=0x8800
+kernel_comp_size=0x400
+fdt_addr_r=0x8c00
+scriptaddr=0x8c10
+pxefile_addr_r=0x8c20
+ramdisk_addr_r=0x8c30
+type_guid_gpt_loader1=5B193300-FC78-40CD-8002-E86C45580B47
+type_guid_gpt_loader2=2E54B353-1271-4842-806F-E436D6AF6985
+type_guid_gpt_system=0FC63DAF-8483-4772-8E79-3D69D8477DE4
+partitions=
+name=loader1,start=17K,size=1M,type=${type_guid_gpt_loader1};
+name=loader2,size=4MB,type=${type_guid_gpt_loader2};
+name=system,size=-,bootable,type=${type_guid_gpt_system};
+fdtfile= CONFIG_DEFAULT_FDT_FILE
diff --git a/configs/sifive_unmatched_defconfig 
b/configs/sifive_unmatched_defconfig
index 6a95ab3977..43fc87d3ce 100644
--- a/configs/sifive_unmatched_defconfig
+++ b/configs/sifive_unmatched_defconfig
@@ -23,7 +23,7 @@ CONFIG_ARCH_RV64I=y
 CONFIG_RISCV_SMODE=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8400
-CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr ${fdtcontroladdr};"
 CONFIG_DEFAULT_FDT_FILE="sifive/hifive-unmatched-a00.dtb"
diff --git a/include/configs/sifive-unmatched.h 
b/include/configs/sifive-unmatched.h
index de8bfc1123..27e0912665 100644
--- a/include/configs/sifive-unmatched.h
+++ b/include/configs/sifive-unmatched.h
@@ -13,41 +13,4 @@
 
 #define CFG_SYS_SDRAM_BASE 0x8000
 
-/* Environment options */
-
-#define BOOT_TARGET_DEVICES(func) \
-   func(NVME, nvme, 0) \
-   func(NVME, nvme, 1) \
-   func(USB, usb, 0) \
-   func(MMC, mmc, 0) \
-   func(SCSI, scsi, 0) \
-   func(PXE, pxe, na) \
-   func(DHCP, dhcp, na)
-
-#include 
-
-#define TYPE_GUID_LOADER1  "5B193300-FC78-40CD-8002-E86C45580B47"
-#define TYPE_GUID_LOADER2  "2E54B353-1271-4842-806F-E436D6AF6985"
-#define TYPE_GUID_SYSTEM   "0FC63DAF-8483-4772-8E79-3D69D8477DE4"
-
-#define PARTS_DEFAULT \
-   "name=loader1,start=17K,size=1M,type=${type_guid_gpt_loader1};" \
-   "name=loader2,size=4MB,type=${type_guid_gpt_loader2};" \
-   "name=system,size=-,bootable,type=${type_guid_gpt_system};"
-
-#define CFG_EXTRA_ENV_SETTINGS \
-   "kernel_addr_r=0x8020\0" \
-   "kernel_comp_addr_r=0x8800\0" \
-   "kernel_comp_size=0x400\0" \
-   "fdt_addr_r=0x8c00\0" \
-   "scriptaddr=0x8c10\0" \
-   "pxefile_addr_r=0x8c20\0" \
-   "ramdisk_addr_r=0x8c30\0" \
-   "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
-   "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
-   "type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \
-   "partitions=" PARTS_DEFAULT "\0" \
-   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
-   BOOTENV
-
 #endif /* __SIFIVE_UNMATCHED_H */
-- 
2.17.1

Re: [PATCH 00/21] Qualcomm generic board support

[Caleb Connolly]

On 05/12/2023 07:44, Sumit Garg wrote:
> Hi Simon,
> 
> On Tue, 5 Dec 2023 at 06:22, Simon Glass  wrote:
>>
>> Hi Sumit,
>>
>> On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
>>>
>>> Hi Caleb,
>>>
>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  
>>> wrote:
[...]
 == DT loading ==

 Previously, boards used the FDT blob embedded into U-Boot (via
 OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
 bootloader, so we can instead rely on the first-stage bootloader to
 populate some useful FDT properties for us (notably the /memory node and
 KASLR seed) and fetch the DTB that it provides. Combined with the memory
 map changes above, this let's us entirely avoid configuring the memory
 map explicitly.
>>>
>>> Since with this change, we don't need to embed FDT blob in the u-boot
>>> binary, so I was thinking if we really need to import DTs from Linux
>>> for different platforms and then play a catchup game?
>>>
>>> IMO, the build command would look like following if we import
>>> pre-built FDT blob from Linux:
>>>
>>> - Build u-boot::
>>>
>>>$ export CROSS_COMPILE=
>>>$ make qcom_defconfig
>>>$ make
>>>
>>> - gzip u-boot::
>>>
>>>gzip u-boot-nodtb.bin
>>>
>>> - Append dtb to gzipped u-boot::
>>>
>>> cat u-boot-nodtb.bin.gz
>>> /arch/arm64/boot/dts/qcom/your-board.dtb >
>>> u-boot-nodtb.bin.gz-dtb
>>
>> What is this?? Who or what uses a gzipped image with a single DT attached?
> 
> The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
> LK). It is the usual way Linux is booted on these platforms. U-boot is
> being brought into this chain to leverage standardized EFI boot
> processes.

Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm
boards/devices are in right now (with the exception of db410c), with
production devices we can't modify the bootloader without vendors
releasing their signing keys.

For devices that haven't been locked with vendor keys ("Secureboot off"
in Qualcomm terminology, note that this has nothing to do with UEFI
secureboot) we can work towards replacing the bootloader entirely with
U-Boot, I have done a PoC of this on SDM845. In that case, we have to
embed the DTB into U-Boot.
> 
>>
>>>
>>> This would avoid the maintenance burden to keep DT in sync with that
>>> of Linux. And since DT bindings in Linux are backwards compatible, we
>>> can say u-boot should work with DTB picked up from any Linux kernel
>>> stable release.
>>
>> That is not the current situation, unfortunately.
>>
> 
> Hopefully with efforts from Caleb and team we can reach that point soon.
> 
>> U-Boot is moving to using Binman to package the firmware. There needs
>> to be a description of the firmware image for each U-Boot boot. To my
>> way of thinking, rpi is a degenerate form, not something to be copied,
>> due to the closed-source nature of the firmware and its inability to
>> be changed. We do have (in the works) a way to pass a DT using a
>> standard firmware handoff. Perhaps that can be adopted by these
>> closed-source projects?
> 
> Why should we really need firmware handoff if the DT can be passed in
> one of the u-boot boot arguments? Linux kernel does support this
> method to retrieve DT as well.

Unfortunately the chances of Qualcomm releasing bootloader updates to
adopt a standard for chainloading U-Boot on their wholely deprecated
platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no
reason to care, and may not even be around anymore) apply these patches
to their own hacked up fork of the bootloader and ship it to end-users
is honestly even less likely than OEMs releasing the signing keys for
devices they don't support anymore.
> 
>>
>> BTW I am very pleased to see this series and I hope that Qualcomm (via
>> Linaro) can continue to improve its U-Boot support.
> 
> It's good to know, thanks.
> 
> -Sumit
> 
>>
>> [..]
>>
>> Regards,
>> Simon

-- 
// Caleb (they/them)