Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition

[Manorit Chawdhry]

Hi Nishanth,

On 06:13-20231006, Nishanth Menon wrote:
> On 09:46-20231006, Manorit Chawdhry wrote:
> > Hi Nishanth,
> > 
> > On 06:26-20231005, Nishanth Menon wrote:
> > > On 10:29-20231005, Manorit Chawdhry wrote:
> > > > Hi Nishanth,
> > > > 
> > > > On 07:24-20231004, Nishanth Menon wrote:
> > > > > On 10:43-20231004, Manorit Chawdhry wrote:
> > > > > 
> > > > > > These are required to remove the firewall configurations that are 
> > > > > > done
> > > > > > by ROM, those are not the ones that are being handled by OIDs. The
> > > > > 
> > > > > I am not sure I understand this clearly. OIDs are setup to open up
> > > > > firewalls or close firewalls as the system requires and since it
> > > > > is authenticated, not compromiseable.- U-boot by itself (even if
> > > > > authenticated), is not a secure entity for it to dictate the firewall
> > > > > configuration (u-boot must be assumed to be compromised after
> > > > > authentication is complete). So, doing firewall configuration via APIs
> > > > > after boot, to me looks broken approach.
> > > > > 
> > > > 
> > > > I know U-boot ain't that secure given the most trusted entity is always
> > > > gonna be the software that starts up the system, we can't expect those
> > > > to be doing all the work and based on that we have the secure boot
> > > > designed to configure firewalls (that are not owned by anymore) and
> > > > U-boot R5 being one of the early bootloaders do come as a part of it. 
> > > > 
> > > > Regarding the OIDs thing, I don't think the OID in question is looked by
> > > > ROM and ROM always configures some firewalls for it's usecase that are
> > > > present in those arrays. 
> > > > 
> > > > The OID that we are using in the series that you had shared is looked by
> > > > TIFS instead of ROM and TIFS is the entity that is authenticating the
> > > > binary along with setting up the firewalls.
> > > > 
> > > > > > current series that is being worked on is to add additional 
> > > > > > firewalling
> > > > > > support with OIDs that TIFS will be handling.
> > > > > > The above patch is
> > > > > > essentially added to have the same development experience on GP 
> > > > > > devices
> > > > > > similar to HS after the secure boot is done so that people don't 
> > > > > > end up
> > > > > 
> > > > > huh? the code seems to blindly call the 
> > > > > remove_fwl_configs(cbass_hc_cfg0_fwls, 
> > > > > ARRAY_SIZE(cbass_hc_cfg0_fwls));
> > > > > where is the distinction of HS vs GP here? This implementation looks
> > > > > completely broken to me at least.. please correct what I missed here.
> > > > 
> > > > Since this call is used across all SoCs there wasn't any point to make
> > > > the differentiation between GP and HS here, remove_fwl_configs
> > > > internally handles looking at the firewalls and disabling them if they
> > > > are enabled ( Which would be only in the case of HS devices ), for GP it
> > > > would automatically by a noop.
> > > 
> > > Correct me if I understand the security chain here:
> > > 
> > > ROM sets up firewalls that are needed by itself
> > > TIFS (in multicertificate will setup it's own firewalls)
> > > R5 SPL comes along and opens up other firewalls
> > > Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs 
> > > to
> > > set up firewalls to protect themselves (enforced by TIFS)
> > > A53 SPL and U-boot itself startups but has no ability to change the
> > > protection firewalls enforced by x509 OIDs.
> > > 
> > > Further, firewalls have lockdown bit that enforces the setting (and
> > > cannot be over-ridden) till system restart is requested
> > > 
> > > Is this correct? If so, needs to be clearly documented.
> > 
> > Yes, this seems correct. Will be updating it in the upstream
> > documentation in another series.
> > 
> 
> Thanks. I suggest:
> a) Add documentation as part of firewall series[1] including information
> as to how to customize the flow as needed.
> b) once the firewall series is merged
> c) am69/j784s4 series and add reference in code to the section of
> documentation.

Sure, would do the following in firewalling series. Thanks!

Regards,
Manorit

> 
> [1] 
> https://lore.kernel.org/all/20231004-binman-firewalling-v3-0-e4a102324...@ti.com/
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
> 849D 1736 249D

Re: [PATCH 3/5] smbios: Use SMBIOS 3.0 to support an address above 4GB

[Heinrich Schuchardt]

On 10/8/23 23:36, Simon Glass wrote:

When the SMBIOS table is written to an address above 4GB a 32-bit table
address is not large enough.

Use an SMBIOS3 table in that case.

Signed-off-by: Simon Glass 
---

  include/smbios.h | 22 +-
  lib/smbios.c | 22 ++
  2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/include/smbios.h b/include/smbios.h
index c9df2706f5a6..ddabb558299e 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -12,7 +12,8 @@

  /* SMBIOS spec version implemented */
  #define SMBIOS_MAJOR_VER  3
-#define SMBIOS_MINOR_VER   0
+#define SMBIOS_MINOR_VER   7
+

  enum {
SMBIOS_STR_MAX  = 64,   /* Maximum length allowed for a string */
@@ -54,6 +55,25 @@ struct __packed smbios_entry {
u8 bcd_rev;
  };

+struct __packed smbios3_entry {
+   u8 anchor[5];
+   u8 checksum;
+   u8 length;
+   u8 major_ver;
+
+   u8 minor_ver;
+   u8 docrev;
+   u8 entry_point_rev;
+   u8 reserved;
+   u32 max_struct_size;
+
+   u64 struct_table_address;
+};
+
+/* These two structures should use the same amount of 16-byte-aligned space */
+static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
+ ALIGN(16, sizeof(struct smbios3_entry)));
+
  /* BIOS characteristics */
  #define BIOS_CHARACTERISTICS_PCI_SUPPORTED(1 << 7)
  #define BIOS_CHARACTERISTICS_UPGRADEABLE  (1 << 11)
diff --git a/lib/smbios.c b/lib/smbios.c
index c7a557bc9b7b..82e259f31791 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -487,7 +487,11 @@ ulong write_smbios_table(ulong addr)
addr = ALIGN(addr, 16);
start_addr = addr;

-   addr += sizeof(struct smbios_entry);
+   /*
+* So far we don't know which struct will be used, but they both end
+* up using the same amount of 16-bit-aligned space
+*/
+   addr += max(sizeof(struct smbios_entry), sizeof(struct smbios3_entry));
addr = ALIGN(addr, 16);
tables = addr;

@@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
 */
table_addr = (ulong)map_sysmem(tables, 0);
if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX) {


You have to check the end address of the table not the start address here.

The SMBIOS specification says that you should always supply a 32bit
SMBIOS entry point. Of course this is not possible on boards that don't
have low memory.

In install_smbios_table() this can be achieved by calling
efi_allocate_pages() with EFI_MAX_ALLOCATE_TYPE and a maximum address of
4 GiB - 1. Only if this fails use high memory.

Best regards

Heinrich


+   struct smbios3_entry *se;
/*
 * We need to put this >32-bit pointer into the table but the
 * field is only 32 bits wide.
 */
-   printf("WARNING: SMBIOS table_address overflow %llx\n",
-  (unsigned long long)table_addr);
-   addr = 0;
+   printf("WARNING: Using SMBIOS3.0 due to table-address overflow 
%lx\n",
+  table_addr);
+   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
+   memset(se, '\0', sizeof(struct smbios_entry));
+   memcpy(se->anchor, "_SM3_", 5);
+   se->length = sizeof(struct smbios3_entry);
+   se->major_ver = SMBIOS_MAJOR_VER;
+   se->minor_ver = SMBIOS_MINOR_VER;
+   se->docrev = 0;
+   se->entry_point_rev = 1;
+   se->max_struct_size = len;
+   se->struct_table_address = table_addr;
} else {
struct smbios_entry *se;

[PATCH v2] cmd: mbr: Allow 4 MBR partitions without need for extended

[Alexander Gendin]

Current code allows up to 3 MBR partitions without extended one.
If more than 3 partitions are required, then extended partition(s)
must be used.
This commit allows up to 4 primary MBR partitions without the
need for extended partition.

Add mbr test unit. In order to run the test manually, mmc6.img file
of size 12 MiB or greater is required in the same directory as u-boot.
Test also runs automatically via ./test/py/test.py tool.
Running mbr test is only supported in sandbox mode.

Signed-off-by: Alex Gendin 
---
Changes for v2:
- Cleanup coding style
- Adjust commit message to the changes in v2
- Add mmc6 device to sandbox device tree
- Adjust boot/bootdev.c and dm/blk.c tests to include mmc6 in tests
- Auto-create mmc6.img in test_ut_dm_init()
- Add mbr test to the list of tests run by test.py. Test can be run manually
  too via 'ut mbr'.
- Change mbr test to use mmc6.img dedicated to the test, instead of mmc1.img.
- Clear read buffer before reading data from test file.

 arch/sandbox/dts/test.dts |   7 +
 disk/part_dos.c   |   2 +-
 include/test/suites.h |   1 +
 test/boot/bootdev.c   |   2 +-
 test/cmd/Makefile |   1 +
 test/cmd/mbr.c| 471 ++
 test/cmd_ut.c |   4 +
 test/dm/blk.c |  44 ++--
 test/py/tests/test_ut.py  |   7 +-
 9 files changed, 522 insertions(+), 17 deletions(-)
 create mode 100644 test/cmd/mbr.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 6abce9e396..59b7f8ef10 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -41,6 +41,7 @@
mmc3 = "/mmc3";
mmc4 = "/mmc4";
mmc5 = "/mmc5";
+   mmc6 = "/mmc6";
pci0 = 
pci1 = 
pci2 = 
@@ -1101,6 +1102,12 @@
filename = "mmc5.img";
};
 
+   /* This is used for mbr tests */
+   mmc6 {
+   compatible = "sandbox,mmc";
+   filename = "mmc6.img";
+   };
+
pch {
compatible = "sandbox,pch";
};
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 3337438437..567ead7511 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -466,7 +466,7 @@ int layout_mbr_partitions(struct disk_partition *p, int 
count,
ext = [i];
}
 
-   if (count < 4)
+   if (count <= 4)
return 0;
 
if (!ext) {
diff --git a/include/test/suites.h b/include/test/suites.h
index 1c7dc65966..51acbe47b2 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -45,6 +45,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
+int do_ut_mbr(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index 6b29213416..4d125104c7 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -128,7 +128,7 @@ static int bootdev_test_labels(struct unit_test_state *uts)
bootdev_find_by_label("fred0", , ));
 
/* Check unknown sequence number */
-   ut_asserteq(-ENOENT, bootdev_find_by_label("mmc6", , ));
+   ut_asserteq(-ENOENT, bootdev_find_by_label("mmc7", , ));
 
return 0;
 }
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index 6e3d7e919e..2f251e07b4 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_CMD_PINMUX) += pinmux.o
 obj-$(CONFIG_CMD_PWM) += pwm.o
 obj-$(CONFIG_CMD_SEAMA) += seama.o
 ifdef CONFIG_SANDBOX
+obj-$(CONFIG_CMD_MBR) += mbr.o
 obj-$(CONFIG_CMD_READ) += rw.o
 obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
 obj-$(CONFIG_ARM_FFA_TRANSPORT) += armffa.o
diff --git a/test/cmd/mbr.c b/test/cmd/mbr.c
new file mode 100644
index 00..4091ea687f
--- /dev/null
+++ b/test/cmd/mbr.c
@@ -0,0 +1,471 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for mbr command
+ *
+ * Copyright 2023 Matrox Video
+ * Written by Alex Gendin 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Requirements for running test manually:
+ * mmc6.img - File size needs to be at least 12 MiB
+ *
+ * Command to create mmc6.img:
+ * $ dd if=/dev/zero of=mmc6.img bs=12M count=1
+ *
+ * To run this test manually, place mmc6.img into the same directory as u-boot,
+ * then run:
+ * $ ./u-boot -Tc 'ut mbr'
+ *
+ * To run this test as part of U-Boot test:
+ * $ ./test/py/test.py --bd sandbox --build -k ut_dm -v
+ * Note: 

Re: [PATCH 4/5] efi: Use the correct GUID for the SMBIOS table

[Heinrich Schuchardt]

On 10/8/23 23:36, Simon Glass wrote:

EFI does not use the 'anchor string' to determine the SMBIOS table
version, instead preferring to have two separate GUIDs. Use the correct
one, depending on the table version.

Signed-off-by: Simon Glass 
---

  include/efi_api.h   |  4 
  lib/efi_loader/efi_smbios.c | 12 ++--
  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 8f5ef5f680f3..1abac2ed7563 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -430,6 +430,10 @@ struct efi_runtime_services {
EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)

+#define SMBIOS3_TABLE_GUID \
+   EFI_GUID(0xf2fd1544, 0x9794, 0x4a2c, \
+0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94)
+
  #define EFI_LOAD_FILE_PROTOCOL_GUID \
EFI_GUID(0x56ec3091, 0x954c, 0x11d2, \
 0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 48446f654d9b..9ef736853d10 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -15,6 +15,8 @@
  #include 
  #include 

+const efi_guid_t smbios3_guid = SMBIOS3_TABLE_GUID;
+
  enum {
TABLE_SIZE  = SZ_4K,
  };
@@ -26,8 +28,10 @@ enum {
   */
  efi_status_t efi_smbios_register(void)
  {
+   const efi_guid_t *guid;
ulong addr;
efi_status_t ret;
+   void *buf;

addr = gd->arch.smbios_start;


Why did you define the macro gd_smbios_start() if it does not point to
the correct field and you don't use it? See
50834884a815 ("Record the position of the SMBIOS tables")


if (!addr) {
@@ -43,8 +47,12 @@ efi_status_t efi_smbios_register(void)
log_debug("EFI using SMBIOS tables at %lx\n", addr);

/* Install SMBIOS information as configuration table */
-   return efi_install_configuration_table(_guid,
-  map_sysmem(addr, 0));
+   buf = map_sysmem(addr, 10);


Where does this arbitrary value of 10 come from?

The second parameter can safely be set to 0 as the SMBIOS table is not
in PCIe mapped memory on the sandbox.


+   guid = !memcmp(buf, "_SM_", 4) ? _guid : _guid;
+   ret = efi_install_configuration_table(guid, buf);
+   unmap_sysmem(buf);


Even on the sandbox this is a NOP as this is not a PCIe address.

Best regards

Heinrich


+
+   return ret;
  }

  static int install_smbios_table(void)

[PATCH v3] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[John Clark]

The NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.

There are four variants depending on the DRAM size: 4G/32GB eMMC,
8G/64GB eMMC, 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR

Specifications:
CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz)
+ 4x Cortex-A55 (up to 1.8GHz)
GPU: Mali-G610 MP4
VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
 4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
NPU: 6TOPs, supports INT4/INT8/INT16/FP16
RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
eMMC: 0GB/32GB/64GB/256GB HS400
MicroSD Slot: MicroSD SDR104
PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host,
  supports M.2 WiFi and Bluetooth
4G Module: MiniPCIe x1, MicroSIM Card Slot x1
Audio Out: 3.5mm jack for stereo headphone output
Audio In: 2.0mm PH-2A connector for analog microphone input
Video Input: standard HDMI input port, up to 4Kp60
2x 4-lane MIPI-CSI, compatible with MIPI V1.2
Video Output: 2x standard HDMI output ports compatible with HDMI2.1,
  HDMI2.0, and HDMI1.4
2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
USB-A: USB 3.0, Type A
USB-C: Full function USB Type‑C port, DP display up to 4Kp60, USB 3.0
40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs,
8x PWMs, 2x I2Ss, 28x GPIOs
Debug UART: 3 Pin 2.54mm header, 3V level, 150bps
Onboard IR receiver: 38KHz carrier frequency
RTC Battery: 2 Pin 1.27/1.25mm RTC battery connector for low power
 RTC IC HYM8563TS
5V Fan connector
Working Temperature: 0C to 70C
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)

Kernel commits:
893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")

Signed-off-by: John Clark 
---

Changes in v3:
- The vendor device tree uses "FriendlyElec NanoPC-T6" therefore, use 
FriendlyElec over FriendlyARM.
- Bug: use IS_ENABLED(CONFIG_TARGET_NANOPCT6_RK3588) rather than 
CONFIG_IS_ENABLED(TARGET_NANOPCT6_RK3588)

Changes in v2:
- resync dt from:

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/plain/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts?h=for-next
- config changes:
-CONFIG_PCI_INIT_R=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x10
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
-CONFIG_REGULATOR_PWM=y
-# CONFIG_USB_XHCI_DWC3_OF_SIMPLE is not set
-CONFIG_SPL_USB_DWC3_GENERIC=y
- added board files:
create mode 100644 board/friendlyarm/nanopct6-rk3588/Kconfig
create mode 100644 board/friendlyarm/nanopct6-rk3588/MAINTAINERS
create mode 100644 board/friendlyarm/nanopct6-rk3588/Makefile
create mode 100644 board/friendlyarm/nanopct6-rk3588/nanopct6-rk3588.c
create mode 100644 include/configs/nanopct6-rk3588.h
- improved BROM_LAST_BOOTSOURCE handling for SPI NOR:
if (CONFIG_IS_ENABLED(TARGET_NANOPCT6_RK3588) && bootdevice_brom_id == 4)
bootdevice_ofpath = boot_devices[BROM_BOOTSOURCE_SPINOR];
else
bootdevice_ofpath = boot_devices[bootdevice_brom_id];

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi |  36 +
 arch/arm/dts/rk3588-nanopc-t6.dts | 916 ++
 arch/arm/mach-rockchip/rk3588/Kconfig |  46 +
 arch/arm/mach-rockchip/spl.c  |   8 +-
 board/friendlyelec/nanopc-t6-rk3588/Kconfig   |  15 +
 .../friendlyelec/nanopc-t6-rk3588/MAINTAINERS |   9 +
 board/friendlyelec/nanopc-t6-rk3588/Makefile  |   6 +
 .../nanopc-t6-rk3588/nanopc-t6-rk3588.c   |  39 +
 configs/nanopc-t6-rk3588_defconfig| 109 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 include/configs/nanopc-t6-rk3588.h|  15 +
 12 files changed, 1199 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-nanopc-t6.dts
 create mode 100644 board/friendlyelec/nanopc-t6-rk3588/Kconfig
 create mode 100644 board/friendlyelec/nanopc-t6-rk3588/MAINTAINERS
 create mode 100644 board/friendlyelec/nanopc-t6-rk3588/Makefile
 create mode 100644 board/friendlyelec/nanopc-t6-rk3588/nanopc-t6-rk3588.c
 create mode 100644 configs/nanopc-t6-rk3588_defconfig
 create mode 100644 include/configs/nanopc-t6-rk3588.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7..6a4335cf9c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -189,6 +189,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+   

Re: [PATCH v2 3/3] mx28evk: Add USB Mass Storage support

[Marek Vasut]

On 10/8/23 22:59, Fabio Estevam wrote:

From: Fabio Estevam 

Select the USB options to allow running "ums 0 mmc 0".

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Remove unrelated config options. (Marek)

  configs/mx28evk_defconfig | 12 
  1 file changed, 12 insertions(+)

diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index df0cceaea719..0b7c4b252ff0 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -32,6 +32,8 @@ CONFIG_CMD_DM=y
  CONFIG_CMD_GPIO=y
  CONFIG_CMD_MMC=y
  CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
  CONFIG_CMD_CACHE=y
  CONFIG_CMD_DATE=y
  CONFIG_CMD_EXT4=y
@@ -65,3 +67,13 @@ CONFIG_RTC_MXS=y
  CONFIG_DM_SERIAL=y
  CONFIG_SPI=y
  CONFIG_USB=y
+CONFIG_SPL_USB_HOST=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MAX_CONTROLLER_COUNT=2
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_SPL_USB_SDP_SUPPORT=y


But the SPL SDP is still here ^ , how come ?

Re: [PATCH] arm: rpi: explicitly enumerate mmc boot targets

[Ben Wolsieffer]

Hi Peter,

On Sun, Oct 08, 2023 at 07:21:57PM +0100, Peter Robinson wrote:
> On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer  wrote:
> >
> > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > fail to boot. c771e5b explains this approach as follows:
> >
> > > We don't need to specify the mmc devices individually, since they are
> > > used in order from 0 to 2, and standard boot uses that order anyway.
> >
> > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > interface, and, when this fails, moves on to attempt the USB and network
> > boot targets rather than trying mmc0.
> 
> Really? It shouldn't be enumerating it if it's not defined in device
> tree, I've not seen this in my testing.

It does seem odd, but U-Boot definitely sees two MMC interfaces:

U-Boot> mmc list
mmcnr@7e30: 1
mmc@7e34: 0 (SD)

> 
> > This patch explicitly enumerates the mmc interfaces, causing each to be
> > attempted in turn. This matches what is done on other boards, and allows
> > the system to boot successfully.
> >
> > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > Signed-off-by: Ben Wolsieffer 
> > ---
> >  board/raspberrypi/rpi/rpi.env | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> > index 30228285ed..02210b97b5 100644
> > --- a/board/raspberrypi/rpi/rpi.env
> > +++ b/board/raspberrypi/rpi/rpi.env
> > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> >  fdt_addr_r=0x0260
> >  ramdisk_addr_r=0x0270
> >
> > -boot_targets=mmc usb pxe dhcp
> > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> 
> Why are you adding mmc1 and mmc2 if they're not connected?

I was trying to match the old distro boot behavior, which had three MMC
interfaces listed.

Re: [PATCH] arm: rpi: explicitly enumerate mmc boot targets

[Ben Wolsieffer]

Hi Simon,

On Sat, Oct 07, 2023 at 02:18:48PM -0600, Simon Glass wrote:
> Hi Ben,
> 
> On Sat, 7 Oct 2023 at 09:55, Ben Wolsieffer  wrote:
> >
> > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > fail to boot. c771e5b explains this approach as follows:
> >
> > > We don't need to specify the mmc devices individually, since they are
> > > used in order from 0 to 2, and standard boot uses that order anyway.
> >
> > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > interface, and, when this fails, moves on to attempt the USB and network
> > boot targets rather than trying mmc0.
> >
> > This patch explicitly enumerates the mmc interfaces, causing each to be
> > attempted in turn. This matches what is done on other boards, and allows
> > the system to boot successfully.
> >
> > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > Signed-off-by: Ben Wolsieffer 
> > ---
> >  board/raspberrypi/rpi/rpi.env | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Does this patch help? [1]. Alternatively, if you just remove that
> variable entirely, does it do the right thing?

Yes, trying either of those suggestions makes it work correctly.

> 
> Regards,
> Simon
> 
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/


Thanks, Ben

Re: [PATCH] ARM: psci: move GIC address override to Kconfig

[Sam Edwards]

On 10/1/23 16:52, Andre Przywara wrote:

As the code to switch an ARM core from secure to the non-secure state
needs to know the base address of the Generic Interrupt Controller
(GIC), we read an Arm Cortex defined system register that is supposed to
hold that base address. However there are SoCs out there that get this
wrong, and this CBAR register either reads as 0 or points to the wrong
address. To accommodate those systems, so far we use a macro defined in
some platform specific header files, for affected boards.

To simplify future extensions, replace that macro with a Kconfig variable
that holds this override address, and define a default value for SoCs
that need it.


Hi Andre,

Looks great to me. I'll update my PSCI series atop this once either this 
or the R528 series lands (I don't want my series to depend on *two* 
pending patchsets).




Signed-off-by: Andre Przywara 

Reviewed-by: Sam Edwards 

Cheers,
Sam

[PATCH 1/5] smbios: Refactor 32-bit code into an else statement

[Simon Glass]

In preparation for adding support for SMBIOS3 move this code into an
else statement. There is no functional change.

Signed-off-by: Simon Glass 
---

 lib/smbios.c | 38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/lib/smbios.c b/lib/smbios.c
index d7f4999e8b2a..96f67cd6ad7b 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -509,14 +509,6 @@ ulong write_smbios_table(ulong addr)
len += tmp;
}
 
-   memcpy(se->anchor, "_SM_", 4);
-   se->length = sizeof(struct smbios_entry);
-   se->major_ver = SMBIOS_MAJOR_VER;
-   se->minor_ver = SMBIOS_MINOR_VER;
-   se->max_struct_size = max_struct_size;
-   memcpy(se->intermediate_anchor, "_DMI_", 5);
-   se->struct_table_length = len;
-
/*
 * We must use a pointer here so things work correctly on sandbox. The
 * user of this table is not aware of the mapping of addresses to
@@ -532,16 +524,28 @@ ulong write_smbios_table(ulong addr)
   (unsigned long long)table_addr);
addr = 0;
goto out;
+   } else {
+   memcpy(se->anchor, "_SM_", 4);
+   se->length = sizeof(struct smbios_entry);
+   se->major_ver = SMBIOS_MAJOR_VER;
+   se->minor_ver = SMBIOS_MINOR_VER;
+   se->max_struct_size = max_struct_size;
+   memcpy(se->intermediate_anchor, "_DMI_", 5);
+   se->struct_table_length = len;
+
+   se->struct_table_address = table_addr;
+
+   se->struct_count = handle;
+
+   /* calculate checksums */
+   istart = (char *)se + SMBIOS_INTERMEDIATE_OFFSET;
+   isize = sizeof(struct smbios_entry) -
+   SMBIOS_INTERMEDIATE_OFFSET;
+   se->intermediate_checksum = table_compute_checksum(istart,
+  isize);
+   se->checksum = table_compute_checksum(se,
+ sizeof(struct smbios_entry));
}
-   se->struct_table_address = table_addr;
-
-   se->struct_count = handle;
-
-   /* calculate checksums */
-   istart = (char *)se + SMBIOS_INTERMEDIATE_OFFSET;
-   isize = sizeof(struct smbios_entry) - SMBIOS_INTERMEDIATE_OFFSET;
-   se->intermediate_checksum = table_compute_checksum(istart, isize);
-   se->checksum = table_compute_checksum(se, sizeof(struct smbios_entry));
 out:
unmap_sysmem(se);
 
-- 
2.42.0.609.gbb76f46606-goog

[PATCH 3/5] smbios: Use SMBIOS 3.0 to support an address above 4GB

[Simon Glass]

When the SMBIOS table is written to an address above 4GB a 32-bit table
address is not large enough.

Use an SMBIOS3 table in that case.

Signed-off-by: Simon Glass 
---

 include/smbios.h | 22 +-
 lib/smbios.c | 22 ++
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/include/smbios.h b/include/smbios.h
index c9df2706f5a6..ddabb558299e 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -12,7 +12,8 @@
 
 /* SMBIOS spec version implemented */
 #define SMBIOS_MAJOR_VER   3
-#define SMBIOS_MINOR_VER   0
+#define SMBIOS_MINOR_VER   7
+
 
 enum {
SMBIOS_STR_MAX  = 64,   /* Maximum length allowed for a string */
@@ -54,6 +55,25 @@ struct __packed smbios_entry {
u8 bcd_rev;
 };
 
+struct __packed smbios3_entry {
+   u8 anchor[5];
+   u8 checksum;
+   u8 length;
+   u8 major_ver;
+
+   u8 minor_ver;
+   u8 docrev;
+   u8 entry_point_rev;
+   u8 reserved;
+   u32 max_struct_size;
+
+   u64 struct_table_address;
+};
+
+/* These two structures should use the same amount of 16-byte-aligned space */
+static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
+ ALIGN(16, sizeof(struct smbios3_entry)));
+
 /* BIOS characteristics */
 #define BIOS_CHARACTERISTICS_PCI_SUPPORTED (1 << 7)
 #define BIOS_CHARACTERISTICS_UPGRADEABLE   (1 << 11)
diff --git a/lib/smbios.c b/lib/smbios.c
index c7a557bc9b7b..82e259f31791 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -487,7 +487,11 @@ ulong write_smbios_table(ulong addr)
addr = ALIGN(addr, 16);
start_addr = addr;
 
-   addr += sizeof(struct smbios_entry);
+   /*
+* So far we don't know which struct will be used, but they both end
+* up using the same amount of 16-bit-aligned space
+*/
+   addr += max(sizeof(struct smbios_entry), sizeof(struct smbios3_entry));
addr = ALIGN(addr, 16);
tables = addr;
 
@@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
 */
table_addr = (ulong)map_sysmem(tables, 0);
if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX) {
+   struct smbios3_entry *se;
/*
 * We need to put this >32-bit pointer into the table but the
 * field is only 32 bits wide.
 */
-   printf("WARNING: SMBIOS table_address overflow %llx\n",
-  (unsigned long long)table_addr);
-   addr = 0;
+   printf("WARNING: Using SMBIOS3.0 due to table-address overflow 
%lx\n",
+  table_addr);
+   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
+   memset(se, '\0', sizeof(struct smbios_entry));
+   memcpy(se->anchor, "_SM3_", 5);
+   se->length = sizeof(struct smbios3_entry);
+   se->major_ver = SMBIOS_MAJOR_VER;
+   se->minor_ver = SMBIOS_MINOR_VER;
+   se->docrev = 0;
+   se->entry_point_rev = 1;
+   se->max_struct_size = len;
+   se->struct_table_address = table_addr;
} else {
struct smbios_entry *se;
 
-- 
2.42.0.609.gbb76f46606-goog

[PATCH 5/5] smbios: Require the caller to align the SMBIOS table

[Simon Glass]

All callers handle this alignment, so drop the unnecessary code. This
simplifies things a little.

Signed-off-by: Simon Glass 
---

 include/smbios.h | 5 +
 lib/smbios.c | 2 --
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/include/smbios.h b/include/smbios.h
index ddabb558299e..31d997287588 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -248,12 +248,9 @@ static inline void fill_smbios_header(void *table, int 
type,
  *
  * This writes SMBIOS table at a given address.
  *
- * @addr:  start address to write SMBIOS table. If this is not
- * 16-byte-aligned then it will be aligned before the table is
- * written.
+ * @addr:  start address to write SMBIOS table (must be 16-byte-aligned)
  * Return: end address of SMBIOS table (and start address for next entry)
  * or NULL in case of an error
- *
  */
 ulong write_smbios_table(ulong addr);
 
diff --git a/lib/smbios.c b/lib/smbios.c
index 82e259f31791..735a9487c019 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -483,8 +483,6 @@ ulong write_smbios_table(ulong addr)
ctx.dev = NULL;
}
 
-   /* 16 byte align the table address */
-   addr = ALIGN(addr, 16);
start_addr = addr;
 
/*
-- 
2.42.0.609.gbb76f46606-goog

[PATCH 4/5] efi: Use the correct GUID for the SMBIOS table

[Simon Glass]

EFI does not use the 'anchor string' to determine the SMBIOS table
version, instead preferring to have two separate GUIDs. Use the correct
one, depending on the table version.

Signed-off-by: Simon Glass 
---

 include/efi_api.h   |  4 
 lib/efi_loader/efi_smbios.c | 12 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 8f5ef5f680f3..1abac2ed7563 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -430,6 +430,10 @@ struct efi_runtime_services {
EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
 0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
 
+#define SMBIOS3_TABLE_GUID \
+   EFI_GUID(0xf2fd1544, 0x9794, 0x4a2c, \
+0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94)
+
 #define EFI_LOAD_FILE_PROTOCOL_GUID \
EFI_GUID(0x56ec3091, 0x954c, 0x11d2, \
 0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 48446f654d9b..9ef736853d10 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 
+const efi_guid_t smbios3_guid = SMBIOS3_TABLE_GUID;
+
 enum {
TABLE_SIZE  = SZ_4K,
 };
@@ -26,8 +28,10 @@ enum {
  */
 efi_status_t efi_smbios_register(void)
 {
+   const efi_guid_t *guid;
ulong addr;
efi_status_t ret;
+   void *buf;
 
addr = gd->arch.smbios_start;
if (!addr) {
@@ -43,8 +47,12 @@ efi_status_t efi_smbios_register(void)
log_debug("EFI using SMBIOS tables at %lx\n", addr);
 
/* Install SMBIOS information as configuration table */
-   return efi_install_configuration_table(_guid,
-  map_sysmem(addr, 0));
+   buf = map_sysmem(addr, 10);
+   guid = !memcmp(buf, "_SM_", 4) ? _guid : _guid;
+   ret = efi_install_configuration_table(guid, buf);
+   unmap_sysmem(buf);
+
+   return ret;
 }
 
 static int install_smbios_table(void)
-- 
2.42.0.609.gbb76f46606-goog

[PATCH 2/5] smbios: Move the rest of the SMBIOS2 code

[Simon Glass]

Move all of this logic into the else clause, since it will not be used
for SMBIOS3

Signed-off-by: Simon Glass 
---

 lib/smbios.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/lib/smbios.c b/lib/smbios.c
index 96f67cd6ad7b..c7a557bc9b7b 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -464,9 +464,8 @@ static struct smbios_write_method smbios_write_funcs[] = {
 ulong write_smbios_table(ulong addr)
 {
ofnode parent_node = ofnode_null();
-   struct smbios_entry *se;
+   ulong table_addr, start_addr;
struct smbios_ctx ctx;
-   ulong table_addr;
ulong tables;
int len = 0;
int max_struct_size = 0;
@@ -486,9 +485,7 @@ ulong write_smbios_table(ulong addr)
 
/* 16 byte align the table address */
addr = ALIGN(addr, 16);
-
-   se = map_sysmem(addr, sizeof(struct smbios_entry));
-   memset(se, 0, sizeof(struct smbios_entry));
+   start_addr = addr;
 
addr += sizeof(struct smbios_entry);
addr = ALIGN(addr, 16);
@@ -523,8 +520,11 @@ ulong write_smbios_table(ulong addr)
printf("WARNING: SMBIOS table_address overflow %llx\n",
   (unsigned long long)table_addr);
addr = 0;
-   goto out;
} else {
+   struct smbios_entry *se;
+
+   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
+   memset(se, '\0', sizeof(struct smbios_entry));
memcpy(se->anchor, "_SM_", 4);
se->length = sizeof(struct smbios_entry);
se->major_ver = SMBIOS_MAJOR_VER;
@@ -545,9 +545,8 @@ ulong write_smbios_table(ulong addr)
   isize);
se->checksum = table_compute_checksum(se,
  sizeof(struct smbios_entry));
+   unmap_sysmem(se);
}
-out:
-   unmap_sysmem(se);
 
return addr;
 }
-- 
2.42.0.609.gbb76f46606-goog

[PATCH 0/5] smbios: Deal with tables beyond 4GB

[Simon Glass]

When the malloc() region extends beyond 4GB on ARM we may end up with
an SMBIOS table in that region.

Add support for writing an SMBIOS3 table, which supports a 64-bit
address.

Note that this problem does not happen on x86 since it requires the
tables to be placed just below 1MB in memory, unless
CONFIG_BLOBLIST_TABLES is enabled.



Simon Glass (5):
  smbios: Refactor 32-bit code into an else statement
  smbios: Move the rest of the SMBIOS2 code
  smbios: Use SMBIOS 3.0 to support an address above 4GB
  efi: Use the correct GUID for the SMBIOS table
  smbios: Require the caller to align the SMBIOS table

 include/efi_api.h   |  4 ++
 include/smbios.h| 27 ++---
 lib/efi_loader/efi_smbios.c | 12 +-
 lib/smbios.c| 77 ++---
 4 files changed, 82 insertions(+), 38 deletions(-)

-- 
2.42.0.609.gbb76f46606-goog

[PATCH] doc: Add a short intro video

[Simon Glass]

This video covers the basics in a short time, so add a link to it.

Signed-off-by: Simon Glass 
---

 doc/learn/talks.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/learn/talks.rst b/doc/learn/talks.rst
index 0bb44aeabe55..d65e3b92be1a 100644
--- a/doc/learn/talks.rst
+++ b/doc/learn/talks.rst
@@ -15,6 +15,9 @@ learn a bit about U-Boot:
   `__
   from Embedded Linux Conference 2023.
 
+* `Introduction to U-Boot for beginners
+  `__
+
 See elinux_talks_ for a more comprehensive list.
 
 .. _elinux_talks: https://elinux.org/Boot_Loaders#U-Boot
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 3/3] mx28evk: Add USB Mass Storage support

[Fabio Estevam]

From: Fabio Estevam 

Select the USB options to allow running "ums 0 mmc 0".

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Remove unrelated config options. (Marek)

 configs/mx28evk_defconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index df0cceaea719..0b7c4b252ff0 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -32,6 +32,8 @@ CONFIG_CMD_DM=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
 CONFIG_CMD_EXT4=y
@@ -65,3 +67,13 @@ CONFIG_RTC_MXS=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_USB=y
+CONFIG_SPL_USB_HOST=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MAX_CONTROLLER_COUNT=2
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_SPL_USB_SDP_SUPPORT=y
-- 
2.34.1

[PATCH v2 2/3] usb: ehci: mxs: Use regulator_set_enable_if_allowed()

[Fabio Estevam]

From: Fabio Estevam 

Since commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable() may be EALREADY or
EBUSY for fixed/GPIO regulators.

Switch to using the more relaxed regulator_set_enable_if_allowed() to
continue if regulator already was enabled or disabled.

This fixes the following error when running the 'ums' command:

=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0xece000
Error enabling VBUS supply
g_dnl_register: failed!, error: -114
g_dnl_register failed

Signed-off-by: Fabio Estevam 
Reviewed-by: Marek Vasut 
---
Changes since v1:
- Only collected Marek's Reviewed-by tag.

 drivers/usb/host/ehci-mxs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 092c79fd4bc5..ddf7cc2d00a7 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -236,9 +236,9 @@ static int ehci_usb_probe(struct udevice *dev)
debug("%s: No vbus supply\n", dev->name);
 
if (!ret && priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply,
-  (type == USB_INIT_DEVICE) ?
-  false : true);
+   ret = regulator_set_enable_if_allowed(priv->vbus_supply,
+ (type == USB_INIT_DEVICE) 
?
+ false : true);
if (ret) {
puts("Error enabling VBUS supply\n");
return ret;
@@ -265,7 +265,7 @@ static int ehci_usb_remove(struct udevice *dev)
 
 #if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply, false);
+   ret = regulator_set_enable_if_allowed(priv->vbus_supply, false);
if (ret) {
puts("Error disabling VBUS supply\n");
return ret;
-- 
2.34.1

[PATCH v2 1/3] usb: ehci: mxs: Fix the USB node pointer retrieval

[Fabio Estevam]

From: Fabio Estevam 

Use dev_ofnode() to retrieve the USB node pointer from the udevice
structure.

This fixes the following build error:

drivers/usb/host/ehci-mxs.c:143:38: error: 'struct udevice' has no member named 
'node_'

Signed-off-by: Fabio Estevam 
Reviewed-by: Marek Vasut 
---
Changes since v1:
- Only collected Marek's Reviewed-by tag.

 drivers/usb/host/ehci-mxs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 147b2fa145d6..092c79fd4bc5 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -136,11 +136,12 @@ static int ehci_usb_ofdata_to_platdata(struct udevice 
*dev)
struct usb_plat *plat = dev_get_plat(dev);
struct ehci_mxs_port *port = >port;
u32 phandle, phy_reg, clk_reg, clk_id;
+   ofnode np = dev_ofnode(dev);
ofnode phy_node, clk_node;
const char *mode;
int ret;
 
-   mode = ofnode_read_string(dev->node_, "dr_mode");
+   mode = ofnode_read_string(np, "dr_mode");
if (mode) {
if (strcmp(mode, "peripheral") == 0)
plat->init_type = USB_INIT_DEVICE;
@@ -151,12 +152,12 @@ static int ehci_usb_ofdata_to_platdata(struct udevice 
*dev)
}
 
/* Read base address of the USB IP block */
-   ret = ofnode_read_u32(dev->node_, "reg", >usb_regs);
+   ret = ofnode_read_u32(np, "reg", >usb_regs);
if (ret)
return ret;
 
/* Read base address of the USB PHY IP block */
-   ret = ofnode_read_u32(dev->node_, "fsl,usbphy", );
+   ret = ofnode_read_u32(np, "fsl,usbphy", );
if (ret)
return ret;
 
-- 
2.34.1

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Sun, 8 Oct 2023 at 12:02, Peter Robinson  wrote:
>
> Hi Simon,
>
> > > So with more testing of 2023.10 in Fedora we found a regression where
> > > the display dies when the vc4 module loads in the kernel. With further
> > > debug it was found that it was due to the new U-Boot and with
> > > bisecting it myself I have found this series is the cause of the
> > > regression.
> > >
> > > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > > image. I can also reproduce it by using the F-38 GA image, no updates
> > > and purely just changing the U-Boot component. I've done my testing on
> > > the RPi4.
> > >
> > > Let me know if you need more information, I believe you have a RPi you
> > > can test with.
> >
> > Thanks for the report. Which rpi should I test with? I take it that
> > vc4 is a kernel module? Do you have the error message?
>
> Well I've been testing on the RPi4 (as I mentioned above), there's no
> direct error message that's directly linked but the screen goes blank
> and turns off, even on a text only install, and yes, on the rpi4 the
> vc4 kernel module deals with driving the HDMI and other output
> interfaces (whereas the v3d is the driver for the render unit), and on
> rpi3 and older vc4 also runs the 3D render module too.

OK I have an rpi4, but I don't get that far:

>>>
U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600)

DRAM:  948 MiB (effective 3.9 GiB)
RPI 4 Model B (0xc03111)
Core:  205 devices, 16 uclasses, devicetree: board
MMC:   mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   eth0: ethernet@7d58
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 3 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot> bootfl scan
Card did not respond to voltage select! : -110
** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi
Card did not respond to voltage select! : -110
Failed to load EFI variables
ERROR: invalid device tree
Boot failed (err=-22)
<<<

Do you know what that might be? I ask because it seems that you are
actually able to boot.

I'll keep looking.

Regards,
Simon
[..]

[PATCH v2 1/1] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[John Clark]

The NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyARM.

There are four variants depending on the DRAM size: 4G/32GB eMMC,
8G/64GB eMMC, 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR

Specifications:
CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz)
+ 4x Cortex-A55 (up to 1.8GHz)
GPU: Mali-G610 MP4
VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
 4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
NPU: 6TOPs, supports INT4/INT8/INT16/FP16
RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
eMMC: 0GB/32GB/64GB/256GB HS400
MicroSD Slot: MicroSD SDR104
PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host,
  supports M.2 WiFi and Bluetooth
4G Module: MiniPCIe x1, MicroSIM Card Slot x1
Audio Out: 3.5mm jack for stereo headphone output
Audio In: 2.0mm PH-2A connector for analog microphone input
Video Input: standard HDMI input port, up to 4Kp60
2x 4-lane MIPI-CSI, compatible with MIPI V1.2
Video Output: 2x standard HDMI output ports compatible with HDMI2.1,
  HDMI2.0, and HDMI1.4
2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
USB-A: USB 3.0, Type A
USB-C: Full function USB Type‑C port, DP display up to 4Kp60, USB 3.0
40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs,
8x PWMs, 2x I2Ss, 28x GPIOs
Debug UART: 3 Pin 2.54mm header, 3V level, 150bps
Onboard IR receiver: 38KHz carrier frequency
RTC Battery: 2 Pin 1.27/1.25mm RTC battery connector for low power
 RTC IC HYM8563TS
5V Fan connector
Working Temperature: 0C to 70C
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)

Kernel commits:
893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")

Signed-off-by: John Clark 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi |  36 +
 arch/arm/dts/rk3588-nanopc-t6.dts | 916 ++
 arch/arm/mach-rockchip/rk3588/Kconfig |  46 +
 arch/arm/mach-rockchip/spl.c  |   8 +-
 board/friendlyarm/nanopct6-rk3588/Kconfig |  15 +
 board/friendlyarm/nanopct6-rk3588/MAINTAINERS |   9 +
 board/friendlyarm/nanopct6-rk3588/Makefile|   6 +
 .../nanopct6-rk3588/nanopct6-rk3588.c |  39 +
 configs/nanopc-t6-rk3588_defconfig| 109 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 include/configs/nanopct6-rk3588.h |  15 +
 12 files changed, 1199 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-nanopc-t6.dts
 create mode 100644 board/friendlyarm/nanopct6-rk3588/Kconfig
 create mode 100644 board/friendlyarm/nanopct6-rk3588/MAINTAINERS
 create mode 100644 board/friendlyarm/nanopct6-rk3588/Makefile
 create mode 100644 board/friendlyarm/nanopct6-rk3588/nanopct6-rk3588.c
 create mode 100644 configs/nanopc-t6-rk3588_defconfig
 create mode 100644 include/configs/nanopct6-rk3588.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7..6a4335cf9c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -189,6 +189,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588-nanopc-t6.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
diff --git a/arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi 
b/arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi
new file mode 100644
index 00..87831c9d43
--- /dev/null
+++ b/arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 John Clark 
+ *
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+_pins {
+   bootph-all;
+};
+
+ {
+   bootph-pre-ram;
+   u-boot,spl-sfc-no-dma;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash@0 {
+   bootph-pre-ram;
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2400>;
+   spi-rx-bus-width = <4>;
+   spi-tx-bus-width = <1>;
+   };
+};
diff --git a/arch/arm/dts/rk3588-nanopc-t6.dts 
b/arch/arm/dts/rk3588-nanopc-t6.dts
new file mode 100644
index 00..97af4f9128
--- /dev/null
+++ b/arch/arm/dts/rk3588-nanopc-t6.dts
@@ -0,0 +1,916 @@
+// SPDX-License-Identifier: 

[PATCH v2 0/1] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[John Clark]

Jonas, thank you for your detailed review.  The explanations for each of config 
change recommendations were especially helpful.

As for the CFG_IRAM_BASE / BROM_LAST_BOOTSOURCE issue, I have made a step 
forward, but expect I will be getting feedback as to a better approach.

Note: This patchset is based on Kever's most recent pull request 
"u-boot-rockchip-20231007" which, as of this writing, has yet to be merged 
upstream.

Finally, I would appreciate any insight as to FriendlyElec vs FriendlyARM 
naming.  Currently, I have documented this as the "FriendlyARM NanoPC-T6" but 
it would seem that it could also be called the "FriendlyElec NanoPC-T6" and be 
equally correct.  It is worth noting that u-boot currently contains support for 
the "FriendlyARM NanoPi2" board/friendlyarm/nanopi2 and thus my use of 
FriendlyARM.

Changes in v2:
- resync dt from:

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/plain/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts?h=for-next
- config changes:
-CONFIG_PCI_INIT_R=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x10
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
-CONFIG_REGULATOR_PWM=y
-# CONFIG_USB_XHCI_DWC3_OF_SIMPLE is not set
-CONFIG_SPL_USB_DWC3_GENERIC=y
- added board files:
create mode 100644 board/friendlyarm/nanopct6-rk3588/Kconfig
create mode 100644 board/friendlyarm/nanopct6-rk3588/MAINTAINERS
create mode 100644 board/friendlyarm/nanopct6-rk3588/Makefile
create mode 100644 board/friendlyarm/nanopct6-rk3588/nanopct6-rk3588.c
create mode 100644 include/configs/nanopct6-rk3588.h
- improved BROM_LAST_BOOTSOURCE handling for SPI NOR:
if (CONFIG_IS_ENABLED(TARGET_NANOPCT6_RK3588) && bootdevice_brom_id == 4)
bootdevice_ofpath = boot_devices[BROM_BOOTSOURCE_SPINOR];
else
bootdevice_ofpath = boot_devices[bootdevice_brom_id];

-- 
2.42.0

Re: [PATCH] arm: rpi: explicitly enumerate mmc boot targets

[Peter Robinson]

On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer  wrote:
>
> Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> fail to boot. c771e5b explains this approach as follows:
>
> > We don't need to specify the mmc devices individually, since they are
> > used in order from 0 to 2, and standard boot uses that order anyway.
>
> In practice, U-Boot first attempts to boot from the unconnected mmc1
> interface, and, when this fails, moves on to attempt the USB and network
> boot targets rather than trying mmc0.

Really? It shouldn't be enumerating it if it's not defined in device
tree, I've not seen this in my testing.

> This patch explicitly enumerates the mmc interfaces, causing each to be
> attempted in turn. This matches what is done on other boards, and allows
> the system to boot successfully.
>
> Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> Signed-off-by: Ben Wolsieffer 
> ---
>  board/raspberrypi/rpi/rpi.env | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> index 30228285ed..02210b97b5 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
>  fdt_addr_r=0x0260
>  ramdisk_addr_r=0x0270
>
> -boot_targets=mmc usb pxe dhcp
> +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp

Why are you adding mmc1 and mmc2 if they're not connected?

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Peter Robinson]

Hi Simon,

> > So with more testing of 2023.10 in Fedora we found a regression where
> > the display dies when the vc4 module loads in the kernel. With further
> > debug it was found that it was due to the new U-Boot and with
> > bisecting it myself I have found this series is the cause of the
> > regression.
> >
> > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > image. I can also reproduce it by using the F-38 GA image, no updates
> > and purely just changing the U-Boot component. I've done my testing on
> > the RPi4.
> >
> > Let me know if you need more information, I believe you have a RPi you
> > can test with.
>
> Thanks for the report. Which rpi should I test with? I take it that
> vc4 is a kernel module? Do you have the error message?

Well I've been testing on the RPi4 (as I mentioned above), there's no
direct error message that's directly linked but the screen goes blank
and turns off, even on a text only install, and yes, on the rpi4 the
vc4 kernel module deals with driving the HDMI and other output
interfaces (whereas the v3d is the driver for the render unit), and on
rpi3 and older vc4 also runs the 3D render module too.

> Regards,
> Simon
>
>
> >
> > Regards,
> > Peter
> >
> > On Thu, Jul 27, 2023 at 10:54 PM Simon Glass  wrote:
> > >
> > > This series moves Raspberry Pi boards over to use standard boot.
> > >
> > > It also moves rpi over to use a text-based environment. Unfortunately it
> > > is not possible to empty the header file due to several CFG options.
> > >
> > > Fix the repeated "and and" while we are here.
> > >
> > > Note that this reduces rodata size by about 4.5KB. We could get another
> > >
> > > for a total image-size saving of about 15KB. This is mostly because
> > > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > > pxe_utils code directly in that case.
> > >
> > > Changes in v3:
> > > - Rebase to -master
> > >
> > > Changes in v2:
> > > - Rebase to -next
> > > - Add new patch to disable DISTRO_DEFAULTS
> > >
> > > Simon Glass (3):
> > >   arm: rpi: Switch to standard boot
> > >   rpi: Disable DISTRO_DEFAULTS
> > >   arm: rpi: Switch to a text environment
> > >
> > >  board/raspberrypi/rpi/rpi.env  |  77 +++
> > >  configs/rpi_0_w_defconfig  |   2 +-
> > >  configs/rpi_2_defconfig|   2 +-
> > >  configs/rpi_3_32b_defconfig|   2 +-
> > >  configs/rpi_3_b_plus_defconfig |   2 +-
> > >  configs/rpi_3_defconfig|   2 +-
> > >  configs/rpi_4_32b_defconfig|   2 +-
> > >  configs/rpi_4_defconfig|   2 +-
> > >  configs/rpi_arm64_defconfig|   2 +-
> > >  configs/rpi_defconfig  |   2 +-
> > >  include/configs/rpi.h  | 134 -
> > >  11 files changed, 86 insertions(+), 143 deletions(-)
> > >  create mode 100644 board/raspberrypi/rpi/rpi.env
> > >
> > > --
> > > 2.41.0.487.g6d72f3e995-goog
> > >

[RFC PATCH v2 5/5] board: stm32f469-disco: add splash screen with stmicroelectronics logo

[Dario Binacchi]

Display the STMicroelectronics logo with features VIDEO_LOGO and
SPLASH_SCREEN on stm32f469-disco board.

Signed-off-by: Dario Binacchi 

---

Changes in v2:
- Add Patrice Chotard's Reviewed-by tag to patches 1, 2 and 3 of the series.
- Fix frame buffer allocation for stm32f469 discovery board.

 configs/stm32f469-discovery_defconfig |   3 +++
 include/configs/stm32f469-discovery.h |   2 ++
 tools/logos/stm32f469-discovery.bmp   | Bin 0 -> 18532 bytes
 3 files changed, 5 insertions(+)
 create mode 100644 tools/logos/stm32f469-discovery.bmp

diff --git a/configs/stm32f469-discovery_defconfig 
b/configs/stm32f469-discovery_defconfig
index 85e795e83e7d..b7e35aeae200 100644
--- a/configs/stm32f469-discovery_defconfig
+++ b/configs/stm32f469-discovery_defconfig
@@ -42,12 +42,15 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
 CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
 CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_DSI=y
 CONFIG_VIDEO_STM32_MAX_XRES=480
 CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
 CONFIG_BMP_16BPP=y
 CONFIG_BMP_24BPP=y
 CONFIG_BMP_32BPP=y
diff --git a/include/configs/stm32f469-discovery.h 
b/include/configs/stm32f469-discovery.h
index 62a7e9af0c56..75bb9cd8d06f 100644
--- a/include/configs/stm32f469-discovery.h
+++ b/include/configs/stm32f469-discovery.h
@@ -31,6 +31,8 @@
"scriptaddr=0x00418000\0"   \
"pxefile_addr_r=0x00428000\0" \
"ramdisk_addr_r=0x00438000\0"   \
+   "splashimage=0x00448000\0" \
+   "splashpos=m,m\0" \
BOOTENV
 
 #endif /* __CONFIG_H */
diff --git a/tools/logos/stm32f469-discovery.bmp 
b/tools/logos/stm32f469-discovery.bmp
new file mode 100644
index 
..ecc8d984218fb13fddf0ba9cf68f2cfad829e289
GIT binary patch
literal 18532
zcmeI4cXZX(r;65wa7qNk~Y5gbqmv5Fw!j5+O7xl9*5>^j-qed+)tS@6wBaRB3{M
zG^rvTq<29PJ?imP-e<18^`MV)eL3Teaql13aUl7vHRoJ>
z%wT@IEylFuj~FL^jJa0Tn0Xc4f9!w`nis$P$Pk$_ux+`yR-Z4+5RH;%y
z?c2AH;7{iH^XL1#;d|MuNYiPtO8m=zEccuLUc7i=rj8tL{`t>;n(v=~XLfJfVn+4u
zWiDU5VCn>CGXMC;KTO@od?q<8o7uN>r}_EkpUhwX`d8EO?IiP$zyIB&6v$~VpTA)K
z_P4*8AHM`O9DaV*d2q_oiOaLS|rxcIM{w>!w$Wrlvu35%ZUye>UrvFE{t^-Zg)P
zu4|(P=Bvk#%nv{OV3y6BV{UwT&0M>3*|d4Hs`=*YZ%mJ-Y39#A{bas<_O1Ey>Q
zO)GQh++YlrF5u%3B;_H5I#N+t8>KmXYbN$+HyeD#$X(7vtNw04a-@bSkc
zEiTr4{p6{6_RTZXA*r_c```a#0boIQDx=f9h;pFTAUr%yA-4<9zSZd^A#
zn>8_KPn|OBmM%5z-l}0brY4(K)e_Cog9pvV)vLhZXVbP;b#wjNHPftO9Bcn*zBql_
z^l8;
zKHawu`se1{nKNem!2V`f*DmJAKmB07`|ew_XZv<@>a)+xl}i`Rkpl-z|F*5oiuvD!_Z!@-kU-KM2hjvLfy<0Xjj~+fS5AWYMTi1VJ9zT3}`M&^DAce
zmaS@L}fO-8*L4+)Uk${{3d@oZ0N}p;@zdu{nMGxVd!Uym|WMiP^qkqglCd
zp&8k$r#b)m=jP6>o95ydUzlwh*PB5d+ncrTzi(D8T42Tv=x06y?;n5s(QH}2*FM
z!aTTt&)mIz%Y1g|koo56*XH)k8)o5q)6FNlcA1SUSDGWN`@ynh=>5!`Vo#HX3^sEo
zO~h}$G)rdAH1nrUF(;26H6MMr(JY$r9{6p=X8X;$m_wF$t
zu2~IkpP0?-)|v@}2C#=?tasBqxOWd9dW`O8&5W_5?o`iK6<3tuxh3Gbnjm5
ze$_0WH_u!=f6hF7aNk@wd)7R9@W33{vj?6rX7aG1=GdWwX6CrDX34BsX7+^f=EAuz
z%txCxn*Dornc>~KniEG4n-M*_ne{7Im@)nOn8h<@n4Oz8n>9<8m|a^po6qshJ7BSG
z!+K)mv6(bHu|NHm1N?G|rg1=+_hC$M4*(N>?Z)qs`WFc~HNu<1h8)4r5cqQCcOoNHmft
z!SJ|bn0TqQBqQgfW9B!dl01}Z(%xaDvV1C)7+-FP5(hno6C2M!N^zw5!|Bf+KmSGQYr5wml9QdhiLQazp*)o9kHmS-K0R0+a~L!mZPzhapj|iFFKZ>4DDjmcG7H=Fw|E4xehEA`
zhFupB2M7g91<)ETPcy40T?B_}j77jTkm#r+eqc3N)_}ND#1WB4L3}&9TL&?5`{;a1-R_(?nb={4f^7G5{aW0~=9MD_}`GUD;j8sIn^Uvsk0K;rbWq$;jgb?wQ64h88L!ot
z$xa>|futPlH7_ftAw7U>SeRY+hVCG7;6hI)KK+^Mi3ZVfTPCt|nmHj0@o~7Bdr?f-%FygkJ_@IX`qa%oc_HdO4*MSn^>rEct4c_;e3t@#k
z9!%?^>r`@eDYO|*{BI@Cp9R~uWiR7ZWDeuG-TSMBm5wR4pV7WW{+le^tf81EEUAoBgoFF^OZow!9wL*;>@Jh`9=~EL_U}uLU(C!FnZ`aG;8=h>swmz^k>Q;*wX5Yap
z-SJk`#z+~(9E*0466|e=jkjvhwIQ}$?9PwKZpd>9{HChpL8ce}Qxudh+sF^Wrw>aa
zlxo#ttW)o$C{&-x@lq64;n^2C1wg=y3LK8)9C-XucJ5_y8$~5uAWMiB_2A}Gn)q%&
zg(?B%Q=*|R^==rH!Q|;Jc=lRp0tP;Kn~l>H!`#Qvo?=f$z$gGYpYVG#_T~$Quj4Oo
z3IT@CUShnPT(I%kkbSmitq&!HtXrM>6H6>PSUWegA$ZYOHYyXycn3u@=P&!slzT
zN(?_|vabpt(u;X(7h=c3$Yq|-$Qss;z&4?1oKZWxVf!Y{4qi4U_E@c>!Ej_ov1gY{
zsdEF-Ie@zHmb63b1bIXDu+wBBC=jn}$Furw0A5m8{8+Oz)<|I=FJm1n>)_c3j)ST0
z|H3+x#X1WsIk41J0cE^DE^Fc%LBBv>)^*W)?E{7#e?QUHEU6
zm#`iwnQR|CN6Mp-KQVahC8V*u_32O|vAgXZA{ZG6MTXEOmXd5=98MLa?y^z>`Fg8e
zIiC9CfFeWQM1(CS{J2WP~ref73#=Ou%
z{d>$xL9cn
z6;ks|#t;lSjl>G8t1A+vRR<`%$32W##;~{x{Zsf*l0Qde*+es1wu<%LhEUQClIm`Mrj?(90#)
z`8}hUowKWErI*bt-TZP=D_1(YqtlrG$nW-(jkFgXjd!W6iR7G#SbG@K{H24<_4TAE
zJ9Mz$jAA&(X1Y*NtS%#5x#`EwAT^9R8^+@pjdH38{S#HscvZv29zGssM(LMeW$
zWjs%A{2s|-ejgoRmhxKB5Euk#V2<*yf#@^pT6RB8gm3
z(DvSVFf}|GUt2CK(XvK{F`K4+cQ(!P1F6x9Q#Y{jLGQ8>2vWo7$9%{SFC$fw
zmX`3jk?Lle^3@RX?gp^`9fv&~$f(v8!zF8p7o+Cy6nBeL2nSvzg;K8D6n#L`8`~>QI}%4qK#c
z-6VgxdP8+1_WC)x>j`AszDBFDwTy_AkiPp=E!AmcsdMkNs!Ysz=q(L9TTRuB2C)lL0KGEXUPQaD
zm$O+35bh6O6rQGg7_JrR75H_sC*?HcI5>fqfzp@GN-JkwS0o2!qlV_ivWp7WK!+m|7!%@y>T=28c0S+g73PN;pz7X
z=3>RcAb8S7=q`Q>luFQDWIT}F1>>RGJ!VBGy{~QYJ8yQMwZq{b1cqPH*K0PKBiV`E
z-+N#Md4}ZUQW$MokPY-*!!f!dMf8ZhqpK)um>Wz*P@l;dh7QgU+u-uW3+K~wS0;A#

[RFC PATCH v2 4/5] ARM: dts: stm32: support display on stm32f469-disco board

[Dario Binacchi]

Add support to Orise Tech OTM8009A display on stm32f469-disco board.

It was necessary to retrieve the framebuffer address from the device tree
because the address returned by the video-uclass driver pointed to a memory
area that was not usable.

Furthermore, unlike Linux, the DSI driver requires the LTDC clock to be
properly probed. Hence, the changes made to the DSI node in
stm32f469-disco-u-boot.dtsi.

Signed-off-by: Dario Binacchi 

---

Changes in v2:
- Add DRAM_SIZE macro.
- Fix frame buffer allocation function so that it is backward compatible
  with boards other than the one it was introduced for (i. e. stm32f469-disco).
  Tested on stm32f469-disco and stm32mp157f-dk2 boards.

 arch/arm/dts/stm32f469-disco-u-boot.dtsi |  4 +++
 configs/stm32f469-discovery_defconfig| 13 ++
 drivers/video/stm32/stm32_ltdc.c | 31 
 3 files changed, 48 insertions(+)

diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi 
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index 8e781c5a7b23..47ba9fa4a783 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -92,7 +92,9 @@
 
  {
clocks = < 0 STM32F4_APB2_CLOCK(DSI)>,
+< 0 STM32F4_APB2_CLOCK(LTDC)>,
 <_hse>;
+   clock-names = "pclk", "px_clk", "ref";
 };
 
  {
@@ -140,6 +142,8 @@
 };
 
  {
+   bootph-all;
+
clocks = < 0 STM32F4_APB2_CLOCK(LTDC)>;
 };
 
diff --git a/configs/stm32f469-discovery_defconfig 
b/configs/stm32f469-discovery_defconfig
index 21c5498466cd..85e795e83e7d 100644
--- a/configs/stm32f469-discovery_defconfig
+++ b/configs/stm32f469-discovery_defconfig
@@ -21,6 +21,7 @@ CONFIG_CMD_GPT=y
 # CONFIG_RANDOM_UUID is not set
 CONFIG_CMD_MMC=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIMER=y
 # CONFIG_ISO_PARTITION is not set
@@ -40,3 +41,15 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
+CONFIG_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_BMP_16BPP=y
+CONFIG_BMP_24BPP=y
+CONFIG_BMP_32BPP=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index 6fd90e33919d..9054db1d78b3 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -495,6 +495,33 @@ static void stm32_ltdc_set_layer1(struct stm32_ltdc_priv 
*priv, ulong fb_addr)
setbits_le32(priv->regs + LTDC_L1CR, LXCR_LEN);
 }
 
+#if IS_ENABLED(CONFIG_TARGET_STM32F469_DISCOVERY)
+static int stm32_ltdc_alloc_fb(struct udevice *dev)
+{
+#define SDRAM_SIZE 0x100 /* 128Mbit = 16 Mbyte = 0x100 */
+   struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+   phys_addr_t cpu;
+   dma_addr_t bus;
+   u64 dma_size;
+   int ret;
+
+   ret = dev_get_dma_range(dev, , , _size);
+   if (ret) {
+   dev_err(dev, "failed to get dma address\n");
+   return ret;
+   }
+
+   uc_plat->base = bus + SDRAM_SIZE - ALIGN(uc_plat->size, uc_plat->align);
+   return 0;
+}
+#else
+static inline int stm32_ltdc_alloc_fb(struct udevice *dev)
+{
+   /* Delegate framebuffer allocation to video-uclass */
+   return 0;
+}
+#endif
+
 static int stm32_ltdc_probe(struct udevice *dev)
 {
struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
@@ -605,6 +632,10 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->crop_h = timings.vactive.typ;
priv->alpha = 0xFF;
 
+   ret = stm32_ltdc_alloc_fb(dev);
+   if (ret)
+   return ret;
+
dev_dbg(dev, "%dx%d %dbpp frame buffer at 0x%lx\n",
timings.hactive.typ, timings.vactive.typ,
VNBITS(priv->l2bpp), uc_plat->base);
-- 
2.42.0

[RFC PATCH v2 2/5] ARM: dts: stm32: make the LTDC clock usable by the clock driver

[Dario Binacchi]

As described in [1], the "clocks" property contains "a phandle to the
clock device node, an index selecting between gated clocks (0) and other
clocks (1), and an index specifying the clock to use." The current version
of the clock driver, unlike the kernel, is currently able to properly
handle nodes with "clocks" properties with an index set to 0.

This patch is preparatory for future developments that require the use
of the LTDC clock.

[1] Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
Signed-off-by: Dario Binacchi 
Reviewed-by: Patrice Chotard 

---

Changes in v2:
- Add Patrice Chotard's Reviewed-by tag.

 arch/arm/dts/stm32f469-disco-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi 
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index c07e2022e4a8..dcc70369cd0d 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -134,6 +134,10 @@
bootph-all;
 };
 
+ {
+   clocks = < 0 STM32F4_APB2_CLOCK(LTDC)>;
+};
+
  {
bootph-all;
 
-- 
2.42.0

[RFC PATCH v2 3/5] ARM: dts: stm32: make the DSI clock usable by the clock driver

[Dario Binacchi]

As described in [1], the "clocks" property contains "a phandle to the
clock device node, an index selecting between gated clocks (0) and other
clocks (1), and an index specifying the clock to use." The current version
of the clock driver, unlike the kernel, is currently able to properly
handle nodes with "clocks" properties with an index set to 0.

This patch is preparatory for future developments that require the use
of the DSI clock.

[1] Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
Signed-off-by: Dario Binacchi 
Reviewed-by: Patrice Chotard 

---

Changes in v2:
- Add Patrice Chotard's Reviewed-by tag.

 arch/arm/dts/stm32f469-disco-u-boot.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi 
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index dcc70369cd0d..8e781c5a7b23 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -90,6 +90,11 @@
bootph-all;
 };
 
+ {
+   clocks = < 0 STM32F4_APB2_CLOCK(DSI)>,
+<_hse>;
+};
+
  {
bootph-all;
 };
-- 
2.42.0

[RFC PATCH v2 1/5] ARM: dts: stm32f469-disco: sync with Linux 6.5

[Dario Binacchi]

Sync the devicetree with linux 6.5 for stm32f746-disco board.

Signed-off-by: Dario Binacchi 
Reviewed-by: Patrice Chotard 

---

Changes in v2:
- Add Patrice Chotard's Reviewed-by tag.

 arch/arm/dts/stm32f469-disco.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32f469-disco.dts b/arch/arm/dts/stm32f469-disco.dts
index 6e0ffc1903be..c9acabf0f530 100644
--- a/arch/arm/dts/stm32f469-disco.dts
+++ b/arch/arm/dts/stm32f469-disco.dts
@@ -119,7 +119,7 @@
};
};
 
-   panel-dsi@0 {
+   panel@0 {
compatible = "orisetech,otm8009a";
reg = <0>; /* dsi virtual channel (0..3) */
reset-gpios = < 7 GPIO_ACTIVE_LOW>;
@@ -138,7 +138,7 @@
status = "okay";
 
port {
-   ltdc_out_dsi: endpoint@0 {
+   ltdc_out_dsi: endpoint {
remote-endpoint = <_in>;
};
};
-- 
2.42.0

[RFC PATCH v2 0/5] Support display on stm32f469-disco board

[Dario Binacchi]

The series adds support for the Orise Tech OTM8009A display on the
stm32f469-disco board. Substantial differences in the drivers for clock
management, LTDC and DSI compared to Linux, made it necessary to modify
the device tree. These changes were made in stm32f469-disco-uboot.dtsi to
avoid altering the Linux device tree. It is therefore desirable, as soon
as possible, to add these drivers the functionalities so that they do not
require device tree properties that deviate from those present in the Linux
version.

Changes in v2:
- Add Patrice Chotard's Reviewed-by tag to patches 1, 2 and 3 of the series.
- Fix frame buffer allocation for stm32f469 discovery board.

Dario Binacchi (5):
  ARM: dts: stm32f469-disco: sync with Linux 6.5
  ARM: dts: stm32: make the LTDC clock usable by the clock driver
  ARM: dts: stm32: make the DSI clock usable by the clock driver
  ARM: dts: stm32: support display on stm32f469-disco board
  board: stm32f469-disco: add splash screen with stmicroelectronics logo

 arch/arm/dts/stm32f469-disco-u-boot.dtsi |  13 ++
 arch/arm/dts/stm32f469-disco.dts |   4 +--
 configs/stm32f469-discovery_defconfig|  16 
 drivers/video/stm32/stm32_ltdc.c |  31 +++
 include/configs/stm32f469-discovery.h|   2 ++
 tools/logos/stm32f469-discovery.bmp  | Bin 0 -> 18532 bytes
 6 files changed, 64 insertions(+), 2 deletions(-)
 create mode 100644 tools/logos/stm32f469-discovery.bmp

-- 
2.42.0

Re: [RFC PATCH 4/5] ARM: dts: stm32: support display on stm32f469-disco board

[Dario Binacchi]

Hello Patrice,

On Wed, Sep 27, 2023 at 8:19 AM Patrice CHOTARD
 wrote:
>
>
>
> On 9/3/23 22:57, Dario Binacchi wrote:
> > Add support to Orise Tech OTM8009A display on stm32f469-disco board.
> >
> > It was necessary to retrieve the framebuffer address from the device tree
> > because the address returned by the video-uclass driver pointed to a memory
> > area that was not usable.
> >
> > Furthermore, unlike Linux, the DSI driver requires the LTDC clock to be
> > properly probed. Hence, the changes made to the DSI node in
> > stm32f469-disco-u-boot.dtsi.
> >
> > Signed-off-by: Dario Binacchi 
> > ---
> >
> >  arch/arm/dts/stm32f469-disco-u-boot.dtsi |  4 +++
> >  configs/stm32f469-discovery_defconfig| 13 +
> >  drivers/video/stm32/stm32_ltdc.c | 37 +++-
> >  3 files changed, 53 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi 
> > b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
> > index 8e781c5a7b23..47ba9fa4a783 100644
> > --- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
> > +++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
> > @@ -92,7 +92,9 @@
> >
> >   {
> >   clocks = < 0 STM32F4_APB2_CLOCK(DSI)>,
> > +  < 0 STM32F4_APB2_CLOCK(LTDC)>,
> ><_hse>;
> > + clock-names = "pclk", "px_clk", "ref";
> >  };
> >
> >   {
> > @@ -140,6 +142,8 @@
> >  };
> >
> >   {
> > + bootph-all;
> > +
> >   clocks = < 0 STM32F4_APB2_CLOCK(LTDC)>;
> >  };
> >
> > diff --git a/configs/stm32f469-discovery_defconfig 
> > b/configs/stm32f469-discovery_defconfig
> > index 35d18d58be6f..9796b8f2d9a5 100644
> > --- a/configs/stm32f469-discovery_defconfig
> > +++ b/configs/stm32f469-discovery_defconfig
> > @@ -21,6 +21,7 @@ CONFIG_CMD_GPT=y
> >  # CONFIG_RANDOM_UUID is not set
> >  CONFIG_CMD_MMC=y
> >  # CONFIG_CMD_SETEXPR is not set
> > +CONFIG_CMD_BMP=y
> >  CONFIG_CMD_CACHE=y
> >  CONFIG_CMD_TIMER=y
> >  # CONFIG_ISO_PARTITION is not set
> > @@ -40,3 +41,15 @@ CONFIG_SPI_FLASH_STMICRO=y
> >  CONFIG_SPI=y
> >  CONFIG_DM_SPI=y
> >  CONFIG_STM32_QSPI=y
> > +CONFIG_VIDEO=y
> > +CONFIG_BACKLIGHT_GPIO=y
> > +CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
> > +CONFIG_VIDEO_STM32=y
> > +CONFIG_VIDEO_STM32_DSI=y
> > +CONFIG_VIDEO_STM32_MAX_XRES=480
> > +CONFIG_VIDEO_STM32_MAX_YRES=800
> > +CONFIG_BMP_16BPP=y
> > +CONFIG_BMP_24BPP=y
> > +CONFIG_BMP_32BPP=y
> > +CONFIG_DM_REGULATOR=y
> > +CONFIG_DM_REGULATOR_FIXED=y
> > diff --git a/drivers/video/stm32/stm32_ltdc.c 
> > b/drivers/video/stm32/stm32_ltdc.c
> > index f48badc517a8..428b0addc43c 100644
> > --- a/drivers/video/stm32/stm32_ltdc.c
> > +++ b/drivers/video/stm32/stm32_ltdc.c
> > @@ -494,6 +494,34 @@ static void stm32_ltdc_set_layer1(struct 
> > stm32_ltdc_priv *priv, ulong fb_addr)
> >   setbits_le32(priv->regs + LTDC_L1CR, LXCR_LEN);
> >  }
> >
> > +#if IS_ENABLED(CONFIG_TARGET_STM32F469_DISCOVERY)
>
> We want to avoid this kind of #define specific to a particular target

If the framebuffer is allocated by the video-uclass module, it is
mapped to the address 0xe0, which does
not appear to be a correct memory zone. Therefore, for the
stm32f469-disco board, a different method for
framebuffer allocation is required, and this seemed to me the most
suitable way. I have submitted the series
as an RFC, and this is one of the points for which I did it. So, I am
open to considering any suggestions you
may have.

Output in case of applied patch:
stm32_display display-controller@40016800: 480x800 16bpp frame buffer
at 0xc0e0

Otherwise:
stm32_display display-controller@40016800: 480x800 16bpp frame buffer
at 0xe0

>
> > +static int stm32_ltdc_get_fb_addr(struct udevice *dev, ulong *base, uint 
> > size,
> > +   uint align)
> > +{
> > + phys_addr_t cpu;
> > + dma_addr_t bus;
> > + u64 dma_size;
> > + int ret;
> > +
> > + ret = dev_get_dma_range(dev, , , _size);
> > + if (ret) {
> > + dev_err(dev, "failed to get dma address\n");
> > + return ret;
> > + }
> > +
> > + *base = bus + 0x100 - ALIGN(size, align);
>
> Why adding 0x100 ? avoid to insert const whithout any description and use 
> a #define instead.

Right, I will add it in version 2.

>
> > + return 0;
> > +}
> > +#else
> > +static int stm32_ltdc_get_fb_addr(struct udevice *dev, ulong *base, uint 
> > size,
> > +   uint align)
> > +{
> > + /* Delegate framebuffer allocation to video-uclass */
> > + *base = 0;
> > + return 0;
> > +}
> > +#endif
> > +
> >  static int stm32_ltdc_probe(struct udevice *dev)
> >  {
> >   struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> > @@ -504,7 +532,7 @@ static int stm32_ltdc_probe(struct udevice *dev)
> >   struct display_timing timings;
> >   struct clk pclk;
> >   struct reset_ctl rst;
> > - ulong rate;
> > + ulong rate, fb_base;
> >   int ret;
> >
> >   priv->regs = dev_read_addr_ptr(dev);
> > @@ -604,6 

[PATCH 2/2] arm: mvebu: clearfog: support 512MB memory size from tlv eeprom

[Josua Mayer]

Handle 2GBit memory size value "2" from tlv eeprom on ddr
initialisation, to support SoMs with 512MB ddr memory.

Signed-off-by: Josua Mayer 
---
 board/solidrun/clearfog/clearfog.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 4f4532b537e..6fa2fe5fe3e 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -159,6 +159,9 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
cf_read_tlv_data();
 
switch (cf_tlv_data.ram_size) {
+   case 2:
+   ifp->memory_size = MV_DDR_DIE_CAP_2GBIT;
+   break;
case 4:
default:
ifp->memory_size = MV_DDR_DIE_CAP_4GBIT;
-- 
2.35.3

[PATCH 1/2] arm: mvebu: clearfog: read number of ddr channels from tlv data

[Josua Mayer]

Extend the existing tlv vendor extension used for ram size by one byte to
also store the number of ddr channels.
The length of the tlv entry can indicate whether the new information is
present. If not default to single channel.

Signed-off-by: Josua Mayer 
---
 board/solidrun/clearfog/clearfog.c | 14 +-
 board/solidrun/common/tlv_data.c   |  7 ++-
 board/solidrun/common/tlv_data.h   |  1 +
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 6edb4221551..4f4532b537e 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -36,7 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define BOARD_GPP_POL_LOW  0x0
 #define BOARD_GPP_POL_MID  0x0
 
-static struct tlv_data cf_tlv_data;
+static struct tlv_data cf_tlv_data = { 0 };
 
 static void cf_read_tlv_data(void)
 {
@@ -168,6 +168,18 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
break;
}
 
+   switch (cf_tlv_data.ram_channels) {
+   default:
+   case 1:
+   for (uint8_t i = 0; i < 5; i++)
+   ifp->as_bus_params[i].cs_bitmask = 0x1;
+   break;
+   case 2:
+   for (uint8_t i = 0; i < 5; i++)
+   ifp->as_bus_params[i].cs_bitmask = 0x3;
+   break;
+   }
+
/* Return the board topology as defined in the board code */
return _topology_map;
 }
diff --git a/board/solidrun/common/tlv_data.c b/board/solidrun/common/tlv_data.c
index 11d6e4a1380..cf5824886c3 100644
--- a/board/solidrun/common/tlv_data.c
+++ b/board/solidrun/common/tlv_data.c
@@ -45,9 +45,14 @@ static void parse_tlv_vendor_ext(struct tlvinfo_tlv 
*tlv_entry,
 
if (val[4] != SR_TLV_CODE_RAM_SIZE)
return;
-   if (tlv_entry->length != 6)
+   if (tlv_entry->length < 6)
return;
td->ram_size = val[5];
+
+   /* extension with additional data field for number of ddr channels */
+   if (tlv_entry->length >= 7) {
+   td->ram_channels = val[6];
+   }
 }
 
 static void parse_tlv_data(u8 *eeprom, struct tlvinfo_header *hdr,
diff --git a/board/solidrun/common/tlv_data.h b/board/solidrun/common/tlv_data.h
index a1432e4b8e1..be3f782ac4a 100644
--- a/board/solidrun/common/tlv_data.h
+++ b/board/solidrun/common/tlv_data.h
@@ -10,6 +10,7 @@ struct tlv_data {
/* Store product name of both SOM and carrier */
char tlv_product_name[2][32];
unsigned int ram_size;
+   uint8_t ram_channels;
 };
 
 void read_tlv_data(struct tlv_data *td);
-- 
2.35.3

[PATCH 0/2] arm: mvebu: clearfog: support additional ddr

[Josua Mayer]

This series adds support for additional memory configuration that
were been produced in the past - most notably
a dual-channel configuration with two 512MB modules.

Josua Mayer (2):
  arm: mvebu: clearfog: read number of ddr channels from tlv data
  arm: mvebu: clearfog: support 512MB memory size from tlv eeprom

 board/solidrun/clearfog/clearfog.c | 17 -
 board/solidrun/common/tlv_data.c   |  7 ++-
 board/solidrun/common/tlv_data.h   |  1 +
 3 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.35.3

[PATCH v4] arm64: versal: Add SelectMAP boot mode identification

[Polak, Leszek]

The SelectMAP configuration interface provides an 8-bit,
16-bit or 32-bit bidirectional data bus interface to the Versal FPGA
configuration logic that can be used for both configuration and readback.

A connected microcontoller to the SelectMAP interface can load boot
image with bitstream, TF-A (ARM Trusted Firmware) and U-Boot.

This commit adds the missing identification of the SelectMAP mode.

Signed-off-by: Polak, Leszek 
Reviewed-by: Stefan Roese 
Cc: Michal Simek 
Cc: Stefan Roese 
---
v2:
- Drop assignment of 'mode' as selectmap is not be supported
  by distro boot
v3:
- Changed E-Mail/Name to be the same as git setup
v4:
- Fixed formatting
---
 arch/arm/mach-versal-net/include/mach/hardware.h | 1 +
 arch/arm/mach-versal/include/mach/hardware.h | 1 +
 board/xilinx/versal-net/board.c  | 3 +++
 board/xilinx/versal/board.c  | 4 
 4 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h 
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 9bddb8b007..767cdd3686 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -66,6 +66,7 @@ struct crp_regs {
 #define EMMC_MODE  0x0006
 #define USB_MODE   0x0007
 #define OSPI_MODE  0x0008
+#define SELECTMAP_MODE 0x000A
 #define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
 #define JTAG_MODE  0x
 #define BOOT_MODE_USE_ALT  0x100
diff --git a/arch/arm/mach-versal/include/mach/hardware.h 
b/arch/arm/mach-versal/include/mach/hardware.h
index 000af974e8..9d1c2f0dcf 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -82,6 +82,7 @@ struct crp_regs {
 #define EMMC_MODE  0x0006
 #define USB_MODE   0x0007
 #define OSPI_MODE  0x0008
+#define SELECTMAP_MODE 0x000A
 #define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
 #define JTAG_MODE  0x
 #define BOOT_MODE_USE_ALT  0x100
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index c18be0c26c..990ca1650a 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -252,6 +252,9 @@ static int boot_targets_setup(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+   case SELECTMAP_MODE:
+   puts("SELECTMAP_MODE\n");
+   break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index e4bdd5d7a3..8c2e614ad8 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -174,6 +174,9 @@ static int boot_targets_setup(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+   case SELECTMAP_MODE:
+   puts("SELECTMAP_MODE\n");
+   break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
@@ -312,6 +315,7 @@ enum env_location env_get_location(enum env_operation op, 
int prio)
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
case JTAG_MODE:
+   case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
-- 
2.25.1

[PATCH 3/3] arm: mvebu: clearfog: Add defconfigs for eMMC booting

[Josua Mayer]

Armada 388 can boot from either eMMC data, boot0 or boot1 partitions.

data partition requires booting from LBA-4096 to avoid conflict with
MBR. When booting from boot0/boot1 environment should be stored there
respectively, too.

Add 3 new defconfigs, for each eMMC partition:
- clearfog_emmcboot0_defconfig
- clearfog_emmcboot1_defconfig
- clearfog_emmcdata_defconfig

Signed-off-by: Josua Mayer 
---
 configs/clearfog_emmcboot0_defconfig | 82 
 configs/clearfog_emmcboot1_defconfig | 82 
 configs/clearfog_emmcdata_defconfig  | 82 
 3 files changed, 246 insertions(+)
 create mode 100644 configs/clearfog_emmcboot0_defconfig
 create mode 100644 configs/clearfog_emmcboot1_defconfig
 create mode 100644 configs/clearfog_emmcdata_defconfig

diff --git a/configs/clearfog_emmcboot0_defconfig 
b/configs/clearfog_emmcboot0_defconfig
new file mode 100644
index 000..215b7708a0d
--- /dev/null
+++ b/configs/clearfog_emmcboot0_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
+CONFIG_TARGET_CLEARFOG=y
+CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
+CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BASE=0xf1012000
+CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x22fd0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x40023000
+CONFIG_SPL_BSS_MAX_SIZE=0x4000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_I2C=y
+CONFIG_SYS_MAXARGS=32
+CONFIG_CMD_TLV_EEPROM=y
+CONFIG_SPL_CMD_TLV_EEPROM=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_MIN_ENTRIES=128
+CONFIG_SYS_MMC_ENV_PART=1
+CONFIG_ARP_TIMEOUT=200
+CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_AHCI_MVEBU=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SPL_I2C_EEPROM=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_MV=y
+CONFIG_MTD=y
+CONFIG_SF_DEFAULT_BUS=1
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_GIGE=y
+CONFIG_MVNETA=y
+CONFIG_MII=y
+CONFIG_MVMDIO=y
+CONFIG_PCI_MVEBU=y
+CONFIG_SCSI=y
+CONFIG_SPL_DEBUG_UART_BASE=0xd0012000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
diff --git a/configs/clearfog_emmcboot1_defconfig 
b/configs/clearfog_emmcboot1_defconfig
new file mode 100644
index 000..59f88c64a2e
--- /dev/null
+++ b/configs/clearfog_emmcboot1_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
+CONFIG_TARGET_CLEARFOG=y
+CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
+CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BASE=0xf1012000
+CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x22fd0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x40023000
+CONFIG_SPL_BSS_MAX_SIZE=0x4000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_I2C=y
+CONFIG_SYS_MAXARGS=32
+CONFIG_CMD_TLV_EEPROM=y
+CONFIG_SPL_CMD_TLV_EEPROM=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_MIN_ENTRIES=128
+CONFIG_SYS_MMC_ENV_PART=2
+CONFIG_ARP_TIMEOUT=200
+CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_AHCI_MVEBU=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SPL_I2C_EEPROM=y
+CONFIG_MMC_SDHCI=y

[PATCH 1/3] arm: mvebu: allow additional 4096 offset for bootable mmc image

[Josua Mayer]

Disarm the error message forcing u-boot/spl image to be located at
sector 0 on eMMC data-partition and microSD.
Offset 0 makes sense on eMMC boot partitions only, data partition must
use 4096 to avoid conflicting with MBR.

Valid offsets when booting from microSD, reported by boot-rom v1.73:

BootROM: Bad header at offset 0200
BootROM: Bad header at offset 4400
BootROM: Bad header at offset 0020
BootROM: Bad header at offset 0040
BootROM: Bad header at offset 0060
BootROM: Bad header at offset 0080
BootROM: Bad header at offset 00A0
BootROM: Bad header at offset 00C0
BootROM: Bad header at offset 00E0
BootROM: Bad header at offset 0100
BootROM: Bad header at offset 0120
BootROM: Bad header at offset 0140
BootROM: Bad header at offset 0160
BootROM: Bad header at offset 0180
BootROM: Bad header at offset 01A0
BootROM: Bad header at offset 01C0
BootROM: Bad header at offset 01E0
BootROM: Bad header at offset 0200
BootROM: Bad header at offset 0220
BootROM: Bad header at offset 0240
BootROM: Bad header at offset 0260
BootROM: Bad header at offset 0280
BootROM: Bad header at offset 02A0
BootROM: Bad header at offset 02C0
BootROM: Bad header at offset 02E0

Valid offsets when booting from eMMC:

BootROM: Bad header at offset 
BootROM: Bad header at offset 0020
Switching BootPartitions.
BootROM: Bad header at offset 
BootROM: Bad header at offset 0020

Fixes: 2226ca17348 ("arm: mvebu: Load U-Boot proper binary in SPL code based on 
kwbimage header")

Signed-off-by: Josua Mayer 
---
 arch/arm/mach-mvebu/spl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 379daa88a4d..0dbc12f66ea 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -71,8 +71,9 @@
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR must be set to 0
 #endif
 #if !defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) || \
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 0
-#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET must be set to 0
+(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 0 && \
+ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 4096)
+#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET must be set to either 
0 or 4096
 #endif
 #endif
 
-- 
2.35.3

[PATCH 2/3] cmd: mvebu/bubt: move eMMC data-partition uboot from LBA-0 to 4096

[Josua Mayer]

A38x bootrom only searches 2 sectors when booting from eMMC,
irregardless of data or boot partition: 0 & 4096.

For eMMC boot partitions sector 0 is fine, but on data partition it
conflicts with MBR.

Change bubt command default to 4096 for eMMC data partition only, to
allow using an MBR partition table on the eMMC data partition while also
booting from it.

Signed-off-by: Josua Mayer 
---
 cmd/mvebu/bubt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index ca24a5c1c4b..eb1fef9243d 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -240,9 +240,14 @@ static int mmc_burn_image(size_t image_size)
 #endif
 
/* SD reserves LBA-0 for MBR and boots from LBA-1,
-* MMC/eMMC boots from LBA-0
+* MMC/eMMC boots from LBA-0 and LBA-4096
 */
-   start_lba = IS_SD(mmc) ? 1 : 0;
+   if (IS_SD(mmc))
+   start_lba = 1;
+   else if (!part)
+   start_lba = 4096;
+   else
+   start_lba = 0;
 #ifdef CONFIG_BLK
blk_count = image_size / mmc->write_bl_len;
if (image_size % mmc->write_bl_len)
-- 
2.35.3

[PATCH 0/3] mvebu: clearfog: add support for emmc boot

[Josua Mayer]

On Armada 388 booting from eMMC is different to SD-Card in two major ways:

- Environment location
- Sectors scanned by Boot-ROM

This patchset first makes it possible to select offset 4096 for
eMMC partition. Here U-Boot can be placed to avoid conflict
conflict with MBR.

Secondly the bubt command is updated to use LBA-4096 for eMMC data
partition only, keeping previous values for SD and boot0/1 unchanged

Finally 3 new defconfigs are added - one for each bootable eMMC partition,
selecting correct offset, and environment partition.

Josua Mayer (3):
  arm: mvebu: allow additional 4096 offset for bootable mmc image
  cmd: mvebu/bubt: move eMMC data-partition uboot from LBA-0 to 4096
  arm: mvebu: clearfog: Add defconfigs for eMMC booting

 arch/arm/mach-mvebu/spl.c|  5 +-
 cmd/mvebu/bubt.c |  9 ++-
 configs/clearfog_emmcboot0_defconfig | 82 
 configs/clearfog_emmcboot1_defconfig | 82 
 configs/clearfog_emmcdata_defconfig  | 82 
 5 files changed, 256 insertions(+), 4 deletions(-)
 create mode 100644 configs/clearfog_emmcboot0_defconfig
 create mode 100644 configs/clearfog_emmcboot1_defconfig
 create mode 100644 configs/clearfog_emmcdata_defconfig

-- 
2.35.3

Re: [PATCH] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[John Clark]

In commit fd6e425, Jonas finds the rock-5b device has a value of 6 at
CFG_IRAM_BASE + 0x10 (0xff10) when booted from spi and creates the
BROM_BOOTSOURCE_SPINOR_RK3588 enum value.
https://github.com/u-boot/u-boot/commit/fd6e425be243dce518a02710482514faccf3c211

When I boot the nanopv-t6 from spi, I am seeing a value of 4 at 0xff10.

We both should be expecting a value of 3:

BROM_BOOTSOURCE_SPINOR = 3,=>  0x 0011   pre-RK3588 variants
BROM_BOOTSOURCE_SPINAND = 4,   =>  0x 0100   NanoPC-T6
BROM_BOOTSOURCE_SPINOR_RK3588 = 6, =>  0x 0110   Rock-5b

Since this is the only use of CFG_IRAM_BASE, I have to wonder if 0xff00
is correct for the RK3588?


I have included the relevant code below for convenience:

/**
 * Boot-device identifiers as used by the BROM
 */
enum {
BROM_BOOTSOURCE_NAND = 1,
BROM_BOOTSOURCE_EMMC = 2,
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
BROM_BOOTSOURCE_SD = 5,
BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
BROM_BOOTSOURCE_USB = 10,
BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
};

extern const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1];

/**
 * Locations of the boot-device identifier in SRAM
 */
#define BROM_BOOTSOURCE_ID_ADDR   (CFG_IRAM_BASE + 0x10)

https://github.com/u-boot/u-boot/blob/master/arch/arm/include/asm/arch-rockchip/bootrom.h


./include/configs/rk3128_common.h:#define CFG_IRAM_BASE 0x1008
./include/configs/px30_common.h:#define CFG_IRAM_BASE 0xff0e
./include/configs/rk3188_common.h:#define CFG_IRAM_BASE 0x1008
./include/configs/rk3568_common.h:#define CFG_IRAM_BASE 0xfdcc
./include/configs/rk3399_common.h:#define CFG_IRAM_BASE 0xff8c
./include/configs/rk3066_common.h:#define CFG_IRAM_BASE 0x1008
./include/configs/rk3308_common.h:#define CFG_IRAM_BASE 0xfff8
./include/configs/rk3368_common.h:#define CFG_IRAM_BASE 0xff8c
./include/configs/rk3288_common.h:#define CFG_IRAM_BASE 0xff70
./include/configs/rk3328_common.h:#define CFG_IRAM_BASE 0xff09
./include/configs/rv1108_common.h:#define CFG_IRAM_BASE 0x1008
./include/configs/rk3588_common.h:#define CFG_IRAM_BASE 0xff00
./include/configs/rk322x_common.h:#define CFG_IRAM_BASE 0x1008
./include/configs/rv1126_common.h:#define CFG_IRAM_BASE 0xff70


On Sun, Oct 8, 2023 at 5:09 AM Kever Yang  wrote:

>
> On 2023/10/8 05:25, John Clark wrote:
> > NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
> >
> > There are four variants depending on the DRAM size: 4G/32GB eMMC,
> 8G/64GB eMMC,
> > 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
>
> So the board is using SPI NOR flash.
>
>
> [...]
>
> > diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
> b/arch/arm/mach-rockchip/rk3588/rk3588.c
> > index b1f535fad5..e08ebfa39b 100644
> > --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
> > +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
> > @@ -40,6 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >   const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> >   [BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
> >   [BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
> > + [BROM_BOOTSOURCE_SPINAND] = "/spi@fe2b/flash@0",
>
> Why need a SPI NAND?
>
> If this is really needed, will be a separate patch to support a new boot
> source from bootrom.
>
>
> Thanks,
> - Kever
>
>

Re: [PATCH] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[Kever Yang]

On 2023/10/8 05:25, John Clark wrote:

NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.

There are four variants depending on the DRAM size: 4G/32GB eMMC, 8G/64GB eMMC,
16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR


So the board is using SPI NOR flash.


[...]


diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c 
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index b1f535fad5..e08ebfa39b 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -40,6 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
+   [BROM_BOOTSOURCE_SPINAND] = "/spi@fe2b/flash@0",


Why need a SPI NAND?

If this is really needed, will be a separate patch to support a new boot 
source from bootrom.



Thanks,
- Kever

Re: [PATCH] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

[Jonas Karlman]

Hi John,

Quick feedback below, will look at schematics and runtime test later.

On 2023-10-07 23:25, John Clark wrote:
> NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
> 
> There are four variants depending on the DRAM size: 4G/32GB eMMC, 8G/64GB 
> eMMC,
> 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
> 
> Specifications:
> CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz) + 4x Cortex-A55 (up to 
> 1.8GHz)
> GPU: Mali-G610 MP4
> VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
>  4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
> NPU: 6TOPs, supports INT4/INT8/INT16/FP16
> RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
> eMMC: 0GB/32GB/64GB/256GB HS400
> MicroSD Slot: MicroSD SDR104
> PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
> Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
> PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host, supports M.2 WiFi 
> and Bluetooth
> 4G Module: MiniPCIe x1, MicroSIM Card Slot x1
> Audio Out: 3.5mm jack for stereo headphone output
> Audio In: 2.0mm PH-2A connector for analog microphone input
> Video Input: standard HDMI input port, up to 4Kp60
> 2x 4-lane MIPI-CSI, compatible with MIPI V1.2
> Video Output: 2x standard HDMI output ports compatible with HDMI2.1, 
> HDMI2.0, and HDMI1.4
> 2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
> USB-A: USB 3.0, Type A
> USB-C: Full function USB Type‑C port, supports DP display up to 4Kp60, 
> USB 3.0
> 40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs, 8x 
> PWMs, 2x I2Ss, 28x GPIOs
> Debug UART: 3 Pin 2.54mm header, 3V level, 150bps
> Onboard IR receiver: 38KHz carrier frequency
> RTC Battery: 2 Pin 1.27/1.25mm RTC battery input connector for low power 
> RTC IC HYM8563TS
> 5V Fan connector
> Working Temperature: 0C to 70C
> Power: 5.5*2.1mm DC Jack, 12VDC input
> Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
> 
> Kernel commits:
> 893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
> a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
> ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")
> 
> Signed-off-by: John Clark 
> ---
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi |  36 +
>  arch/arm/dts/rk3588-nanopc-t6.dts | 916 ++
>  arch/arm/mach-rockchip/rk3588/rk3588.c|   1 +
>  configs/nanopc-t6-rk3588_defconfig| 113 +++
>  5 files changed, 1067 insertions(+)
>  create mode 100644 arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3588-nanopc-t6.dts
>  create mode 100644 configs/nanopc-t6-rk3588_defconfig

This is missing addition of the board to the list in board documentation
and an entry in the evb_rk3588 MAINTAINERS file.

[...]

> diff --git a/arch/arm/dts/rk3588-nanopc-t6.dts 
> b/arch/arm/dts/rk3588-nanopc-t6.dts
> new file mode 100644
> index 00..965bf5263d
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-nanopc-t6.dts
> @@ -0,0 +1,916 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2023 Thomas McKahan
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include 
> +#include "rk3588.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPC-T6";
> + compatible = "friendlyarm,nanopc-t6", "rockchip,rk3588";
> +
> + aliases {
> + mmc0 = 
> + mmc1 = 
> + serial2 = 
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <_det>;
> +
> + simple-audio-card,name = "realtek,rt5616-codec";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,mclk-fs = <256>;
> +
> + simple-audio-card,hp-det-gpio = < RK_PC4 GPIO_ACTIVE_LOW>;
> + simple-audio-card,hp-pin-name = "Headphones";
> +
> + simple-audio-card,widgets =
> + "Headphone", "Headphones",
> + "Microphone", "Microphone Jack";
> + simple-audio-card,routing =
> + "Headphones", "HPOL",
> + "Headphones", "HPOR",
> + "MIC1", "Microphone Jack",
> + "Microphone Jack", "micbias1";
> +
> + simple-audio-card,cpu {
> + sound-dai = <_8ch>;
> + };
> + simple-audio-card,codec {
> + sound-dai = <>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + sys_led: led-0 {
> + gpios = < RK_PB7 GPIO_ACTIVE_HIGH>;
> + label = "system-led";

Re: Pull request: u-boot-rockchip-20231007

[Jonas Karlman]

Hi Kever,

On 2023-10-08 03:13, Kever Yang wrote:
> Hi Jonas,
> 
> On 2023/10/7 18:37, Jonas Karlman wrote:
>> Hi Kever,
>>
>> Looks like the following patch is missing:
>>
>> [v2,7/7] rockchip: rk3568-radxa-e25: Enable pcie3x1 node
>> https://patchwork.ozlabs.org/patch/1816145/
> 
> This patch set does not show in sorted order in the patchwork system.
> 
> I use the last patch(which is 6/7) to apply this series, but 
> unfortunately 7/7 is missing.
> 
> How do you send this patch set? All other patch sets looks OK in system.

I think there was an issue with the mail-server at the time, as a result
mails got delayed and patches ended up in a strange order.

Patchwork list them in wrong/strange order, trying to download the
series as a mbox seem to sort the patches in proper patch order.

> 
> I can pick this patch up later when merge other patches for next PR.

Great, I will re-send the missing patch after this PR has been merged.

Regards,
Jonas

> 
> 
> Thanks,
> 
> - Kever
> 
>>
>> from merged series:
>> [v2,0/7] rockchip: rk3568: Fix use of PCIe bifurcation
>>
>> Do you want me to send it as a new separate patch?
>>
>> Regards,
>> Jonas
>>
>> On 2023-10-07 12:26, Kever Yang wrote:
>>> Hi Tom,
>>>
>>> Please pull the updates for rockchip platform:
>>> - Add Board: rk3568 Bananapi R2Pro;
>>> - Update pcie bifurcation support;
>>> - dwc_eth_qos controller support for rk3568 and rk3588;
>>> - Compressed binary support for U-Boot on rockchip platform;
>>> - dts and config updates for different board and soc;
>>>
>>> CI:
>>> https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/18047
>>>
>>> Thanks,
>>> - Kever
>>>
>>> The following changes since commit be2abe73df58a35da9e8d5afb13fccdf1b0faa8e:
>>>
>>>Merge https://source.denx.de/u-boot/custodians/u-boot-riscv (2023-10-05 
>>> 13:26:44 -0400)
>>>
>>> are available in the Git repository at:
>>>
>>>https://source.denx.de/u-boot/custodians/u-boot-rockchip.git 
>>> tags/u-boot-rockchip-20231007
>>>
>>> for you to fetch changes up to dd8d52c934e8858264f91e8e8e2d8c7d8b059dd7:
>>>
>>>rockchip: rk356x-u-boot: Add bootph-all to i2c0_xfer pinctrl node 
>>> (2023-10-07 16:52:48 +0800)
>>>
>>> 
>>> FUKAUMI Naoki (5):
>>>configs: rockchip: rock-pi-s: use default bootdelay (2s)
>>>arm: dts: rockchip: sync DT for RK3588 series with Linux
>>>arm: dts: rockchip: rock-5b: add support for PCIe3 and NVMe
>>>configs: rockchip: rk3308: use CONFIG_DEFAULT_FDT_FILE
>>>configs: rockchip: rk3308: enable CONFIG_OF_LIBFDT_OVERLAY
>>>
>>> Frank Wunderlich (1):
>>>board: rockchip: Add Bananapi R2Pro Board
>>>
>>> Jonas Karlman (22):
>>>pci: pcie_dw_rockchip: Configure number of lanes and link width speed
>>>phy: rockchip: snps-pcie3: Refactor to use clk_bulk API
>>>phy: rockchip: snps-pcie3: Refactor to use a phy_init ops
>>>phy: rockchip: snps-pcie3: Add bifurcation support for RK3568
>>>phy: rockchip: snps-pcie3: Add support for RK3588
>>>phy: rockchip: naneng-combphy: Use signal from comb PHY on RK3588
>>>rockchip: rk3568-nanopi-r5: Update defconfig for NanoPi R5C and R5S
>>>rockchip: rk3568-nanopi-r5: Enable PCIe on NanoPi R5C and R5S
>>>power: regulator: Only run autoset once for each regulator
>>>rockchip: Port IO-domain driver for RK3568 from linux
>>>rockchip: board: Add minimal generic RK3566/RK3568 board
>>>net: dwc_eth_qos: Drop unused rx_pkt from eqos_priv
>>>net: dwc_eth_qos: Return error code when start fails
>>>net: dwc_eth_qos: Stop spam of RX packet not available message
>>>net: dwc_eth_qos: Add glue driver for GMAC on Rockchip RK3568
>>>net: dwc_eth_qos_rockchip: Add support for RK3588
>>>configs: rockchip: Enable ethernet driver on RK356x boards
>>>configs: rockchip: Enable ethernet driver on RK3588 boards
>>>power: pmic: rk8xx: Use sysreset implementation of the poweroff 
>>> command
>>>rockchip: rk356x: Enable poweroff command
>>>power: pmic: rk8xx: Fix power-on source check in SPL
>>>rockchip: rk356x-u-boot: Add bootph-all to i2c0_xfer pinctrl node
>>>
>>> Joseph Chen (1):
>>>regulator: rk8xx: Return correct voltage for buck converters
>>>
>>> Manoj Sai (4):
>>>spl: fit: support for booting a GZIP-compressed U-boot binary
>>>spl: fit: support for booting a LZMA-compressed U-boot binary
>>>rockchip: Add support to generate GZIP compressed U-boot binary
>>>rockchip: Add support to generate LZMA compressed U-boot binary
>>>
>>> Massimo Pegorer (3):
>>>rockchip: Kconfig: Enable external TPL binary for rk3308
>>>doc: rockchip: Update and improve info on rk3308, TPL and TF-A
>>>configs: rockchip: add DOS_PARTITION to RK3308 boards defconfig
>>>
>>> shengfei Xu (1):
>>>regulator: rk8xx: