Re: [PATCH] EFI: Fix ReadBlocks API reading incorrect sector for, UCLASS_PARTITION devices

[Heinrich Schuchardt]

On 6/29/22 03:02, Paul Barbieri wrote:

 From 7a7dd7f16352fc916279cca05a3fa617f8bbef64 Mon Sep 17 00:00:00 2001
From: Paul Barbieri 
Date: Tue, 28 Jun 2022 20:24:33 -0400
Subject: [PATCH] EFI: Fix ReadBlocks API reading incorrect sector for 
UCLASS_PARTITION devices


The requested partition disk sector incorrectly has the partition start
sector added in twice for UCLASS_PARTITION devices. The 
efi_disk_rw_blocks()

routine adds the diskobj->offset to the requested lba. When the device
is a UCLASS_PARTITION, the dev_read() or dev_write() routine is called
which adds part-gpt_part_info.start. This causes I/O to the wrong sector.

Takahiro Akashi suggested removing the offset field from the efi_disk_obj
structure since disk-uclass.c handles the partition start biasing. Device
types other than UCLASS_PARTITION set the diskobj->offset field to zero
which makes the field unnecessary. This change removes the offset field
from the structure and removes all references from the code which is
isolated to the lib/efi_loader/efi_disk.c module.

This change also adds a test for the EFI ReadBlocks() API in the EFI
selftest code. There is already a test for reading a FAT file. The new
test uses ReadBlocks() to read the same "disk" block and compare it to
the data read from the file system API.


This is not a valid patch:

$ git am /tmp/0.patch
warning: Patch sent with format=flowed; space at the end of lines might 
be lost.
Applying: EFI: Fix ReadBlocks API reading incorrect sector for, 
UCLASS_PARTITION devices

error: corrupt patch at line 11
Patch failed at 0001 EFI: Fix ReadBlocks API reading incorrect sector 
for, UCLASS_PARTITION devices


Please, use 'git send-email' for sending patches not Thunderbird.

Best regards

Heinrich



Signed-Off-by: Paul Barbieri 
Cc: Heinrich Schuchardt 
Cc: AKASHI Takahiro 
---
  lib/efi_loader/efi_disk.c    |  8 +---
  lib/efi_selftest/efi_selftest_block_device.c | 19 +++
  2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 1e82f52dc0..1d700b2a6b 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -35,7 +35,6 @@ const efi_guid_t efi_system_partition_guid = 
PARTITION_SYSTEM_GUID;

   * @dp:    device path to the block device
   * @part:  partition
   * @volume:    simple file system protocol of the partition
- * @offset:    offset into disk for simple partition
   * @dev:   associated DM device
   */
  struct efi_disk_obj {
@@ -47,7 +46,6 @@ struct efi_disk_obj {
     struct efi_device_path *dp;
     unsigned int part;
     struct efi_simple_file_system_protocol *volume;
-   lbaint_t offset;
     struct udevice *dev; /* TODO: move it to efi_object */
  };

@@ -117,7 +115,6 @@ static efi_status_t efi_disk_rw_blocks(struct 
efi_block_io *this,

     diskobj = container_of(this, struct efi_disk_obj, ops);
     blksz = diskobj->media.block_size;
     blocks = buffer_size / blksz;
-   lba += diskobj->offset;

     EFI_PRINT("blocks=%x lba=%llx blksz=%x dir=%d\n",
   blocks, lba, blksz, direction);
@@ -440,13 +437,11 @@ static efi_status_t efi_disk_add_dev(

     diskobj->dp = efi_dp_append_node(dp_parent, node);
     efi_free_pool(node);
-   diskobj->offset = part_info->start;
     diskobj->media.last_block = part_info->size - 1;
     if (part_info->bootable & PART_EFI_SYSTEM_PARTITION)
     guid = _system_partition_guid;
     } else {
     diskobj->dp = efi_dp_from_part(desc, part);
-   diskobj->offset = 0;
     diskobj->media.last_block = desc->lba - 1;
     }
     diskobj->part = part;
@@ -501,12 +496,11 @@ static efi_status_t efi_disk_add_dev(
     *disk = diskobj;

     EFI_PRINT("BlockIO: part %u, present %d, logical %d, removable %d"
- ", offset " LBAF ", last_block %llu\n",
+ ", last_block %llu\n",
   diskobj->part,
   diskobj->media.media_present,
   diskobj->media.logical_partition,
   diskobj->media.removable_media,
- diskobj->offset,
   diskobj->media.last_block);

     /* Store first EFI system partition */
diff --git a/lib/efi_selftest/efi_selftest_block_device.c 
b/lib/efi_selftest/efi_selftest_block_device.c

index 60fa655766..ef6bdafe2e 100644
--- a/lib/efi_selftest/efi_selftest_block_device.c
+++ b/lib/efi_selftest/efi_selftest_block_device.c
@@ -11,6 +11,7 @@
   * ConnectController is used to setup partitions and to install the 
simple

   * file protocol.
   * A known file is read from the file system and verified.
+ * Test that the read_blocks API correctly reads a block from the device.
   */

  #include 
@@ -312,6 +313,7 @@ static int execute(void)
     char buf[16] 

Re: [PATCH] EFI: Fix ReadBlocks API reading incorrect sector for, UCLASS_PARTITION devices

[AKASHI Takahiro]

Hi Paul,

On Tue, Jun 28, 2022 at 09:02:47PM -0400, Paul Barbieri wrote:
> From 7a7dd7f16352fc916279cca05a3fa617f8bbef64 Mon Sep 17 00:00:00 2001
> From: Paul Barbieri 
> Date: Tue, 28 Jun 2022 20:24:33 -0400
> Subject: [PATCH] EFI: Fix ReadBlocks API reading incorrect sector for
> UCLASS_PARTITION devices
> 
> The requested partition disk sector incorrectly has the partition start
> sector added in twice for UCLASS_PARTITION devices. The efi_disk_rw_blocks()
> routine adds the diskobj->offset to the requested lba. When the device
> is a UCLASS_PARTITION, the dev_read() or dev_write() routine is called
> which adds part-gpt_part_info.start. This causes I/O to the wrong sector.
> 
> Takahiro Akashi suggested removing the offset field from the efi_disk_obj
> structure since disk-uclass.c handles the partition start biasing. Device
> types other than UCLASS_PARTITION set the diskobj->offset field to zero
> which makes the field unnecessary. This change removes the offset field
> from the structure and removes all references from the code which is
> isolated to the lib/efi_loader/efi_disk.c module.

Your change on efi_disk.c looks good, but

> This change also adds a test for the EFI ReadBlocks() API in the EFI
> selftest code. There is already a test for reading a FAT file. The new
> test uses ReadBlocks() to read the same "disk" block and compare it to
> the data read from the file system API.

Your test will never exercise the code you added in efi_disk.c
(or efi_disk_rw_blocks()) because "block device" selftest uses
its own block device driver.

-Takahiro Akashi

> Signed-Off-by: Paul Barbieri 
> Cc: Heinrich Schuchardt 
> Cc: AKASHI Takahiro 
> ---
>  lib/efi_loader/efi_disk.c    |  8 +---
>  lib/efi_selftest/efi_selftest_block_device.c | 19 +++
>  2 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index 1e82f52dc0..1d700b2a6b 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -35,7 +35,6 @@ const efi_guid_t efi_system_partition_guid =
> PARTITION_SYSTEM_GUID;
>   * @dp:    device path to the block device
>   * @part:  partition
>   * @volume:    simple file system protocol of the partition
> - * @offset:    offset into disk for simple partition
>   * @dev:   associated DM device
>   */
>  struct efi_disk_obj {
> @@ -47,7 +46,6 @@ struct efi_disk_obj {
>     struct efi_device_path *dp;
>     unsigned int part;
>     struct efi_simple_file_system_protocol *volume;
> -   lbaint_t offset;
>     struct udevice *dev; /* TODO: move it to efi_object */
>  };
> 
> @@ -117,7 +115,6 @@ static efi_status_t efi_disk_rw_blocks(struct
> efi_block_io *this,
>     diskobj = container_of(this, struct efi_disk_obj, ops);
>     blksz = diskobj->media.block_size;
>     blocks = buffer_size / blksz;
> -   lba += diskobj->offset;
> 
>     EFI_PRINT("blocks=%x lba=%llx blksz=%x dir=%d\n",
>   blocks, lba, blksz, direction);
> @@ -440,13 +437,11 @@ static efi_status_t efi_disk_add_dev(
> 
>     diskobj->dp = efi_dp_append_node(dp_parent, node);
>     efi_free_pool(node);
> -   diskobj->offset = part_info->start;
>     diskobj->media.last_block = part_info->size - 1;
>     if (part_info->bootable & PART_EFI_SYSTEM_PARTITION)
>     guid = _system_partition_guid;
>     } else {
>     diskobj->dp = efi_dp_from_part(desc, part);
> -   diskobj->offset = 0;
>     diskobj->media.last_block = desc->lba - 1;
>     }
>     diskobj->part = part;
> @@ -501,12 +496,11 @@ static efi_status_t efi_disk_add_dev(
>     *disk = diskobj;
> 
>     EFI_PRINT("BlockIO: part %u, present %d, logical %d, removable %d"
> - ", offset " LBAF ", last_block %llu\n",
> + ", last_block %llu\n",
>   diskobj->part,
>   diskobj->media.media_present,
>   diskobj->media.logical_partition,
>   diskobj->media.removable_media,
> - diskobj->offset,
>   diskobj->media.last_block);
> 
>     /* Store first EFI system partition */
> diff --git a/lib/efi_selftest/efi_selftest_block_device.c
> b/lib/efi_selftest/efi_selftest_block_device.c
> index 60fa655766..ef6bdafe2e 100644
> --- a/lib/efi_selftest/efi_selftest_block_device.c
> +++ b/lib/efi_selftest/efi_selftest_block_device.c
> @@ -11,6 +11,7 @@
>   * ConnectController is used to setup partitions and to install the simple
>   * file protocol.
>   * A known file is read from the file system and verified.
> + * Test that the read_blocks API correctly reads a block from the device.
>   */
> 
>  #include 
> @@ -312,6 +313,7 @@ static int execute(void)
>     char buf[16] __aligned(ARCH_DMA_MINALIGN);
>     u32 part1_size;
>     u64 

Re: [PATCH] RockPi4: Add UEFI capsule update support

[Kever Yang]

Hi Sughosh,

 Thanks for your patch.

On 2022/5/16 14:12, Sughosh Ganu wrote:

hi Peter,

On Sat, 14 May 2022 at 13:44, Peter Robinson  wrote:

On Fri, May 13, 2022 at 7:50 AM Sughosh Ganu  wrote:

Add support for updating the idbloader and u-boot images through the
UEFI capsule update functionality. Enable the modules required for
supporting the functionality.

The implementation is for the updatable images placed on a GPT
partitioned storage device. With the GPT partition devices, the
partition information can be obtained at runtime, and hence the
dfu_alt_info variable needed for the updates is being populated at
runtime.

This requires the partitions containing the idbloader and u-boot
images to be created with the PartitionTypeGUID values set to the
corresponding image type GUID values defined in the platform's config
header(ROCKPI_4{B,C}_IDBLOADER_IMAGE_GUID and
ROCKPI_4{B,C}_UBOOT_IMAGE_GUID).

I think it would be useful to break this patch down into more than one
patch. At least the core changes to evb_rk3399/evb-rk3399.c and the
board specific changes. Also given these changes arre likely of
interest to other boards should  they go to somewhere more central
than evb_rk3399/evb-rk3399.c to enable less code duplication across
rk3399 or even rockchip devices as a whole?

I believe I can move the logic to set dfu_alt_info to some place like
arch/arm/mach-rockchip/board.c. The definition of rk_board_late_init()
can stay in evb-rk3399.c since it is populating the capsule update
structures for the rk3399 family of platforms. Does that sound okay to
you? If so, I will make the changes and send a V2, or if  you have
some other solution in mind, please let me know. Thanks.


Other than Peter's command, please make sure:

All the source code relate to rockpi should go to board/radxa instead of 
board/rockchip/evb-rk3399.c



Thanks,

- Kever



-sughosh


Peter


Signed-off-by: Sughosh Ganu 
---
  arch/arm/mach-rockchip/Kconfig |   1 +
  board/rockchip/evb_rk3399/evb-rk3399.c | 190 -
  configs/rock-pi-4-rk3399_defconfig |   4 +
  configs/rock-pi-4c-rk3399_defconfig|   4 +
  include/configs/rk3399_common.h|  16 +++
  5 files changed, 214 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 18aff5480b..6d13e7b92e 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -246,6 +246,7 @@ config ROCKCHIP_RK3399
 select DM_PMIC
 select DM_REGULATOR_FIXED
 select BOARD_LATE_INIT
+   imply PARTITION_TYPE_GUID
 imply PRE_CONSOLE_BUFFER
 imply ROCKCHIP_COMMON_BOARD
 imply ROCKCHIP_SDRAM_COMMON
diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
b/board/rockchip/evb_rk3399/evb-rk3399.c
index abb76585cf..cc976d9471 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -5,11 +5,27 @@

  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
+#include 
+#include 
  #include 
  #include 

+#define ROCKPI4_UPDATABLE_IMAGES   2
+
+#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
+struct efi_fw_image fw_images[ROCKPI4_UPDATABLE_IMAGES] = {0};
+
+struct efi_capsule_update_info update_info = {
+   .images = fw_images,
+};
+
+u8 num_image_type_guids = ARRAY_SIZE(fw_images);
+#endif
+
  #ifndef CONFIG_SPL_BUILD
  int board_early_init_f(void)
  {
@@ -29,4 +45,176 @@ int board_early_init_f(void)
  out:
 return 0;
  }
-#endif
+
+#if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
+
+#define DFU_ALT_BUF_LEN SZ_1K
+
+static bool board_is_rockpi_4b(void)
+{
+   return CONFIG_IS_ENABLED(TARGET_EVB_RK3399) &&
+   of_machine_is_compatible("radxa,rockpi4b");
+}
+
+static bool board_is_rockpi_4c(void)
+{
+   return CONFIG_IS_ENABLED(TARGET_EVB_RK3399) &&
+   of_machine_is_compatible("radxa,rockpi4c");
+}
+
+static bool updatable_image(struct disk_partition *info)
+{
+   int i;
+   bool ret = false;
+   efi_guid_t image_type_guid;
+
+   uuid_str_to_bin(info->type_guid, image_type_guid.b,
+   UUID_STR_FORMAT_GUID);
+
+   for (i = 0; i < ROCKPI4_UPDATABLE_IMAGES; i++) {
+   if (!guidcmp(_images[i].image_type_id, _type_guid)) {
+   ret = true;
+   break;
+   }
+   }
+
+   return ret;
+}
+
+static void set_image_index(struct disk_partition *info, int index)
+{
+   int i;
+   efi_guid_t image_type_guid;
+
+   uuid_str_to_bin(info->type_guid, image_type_guid.b,
+   UUID_STR_FORMAT_GUID);
+
+   for (i = 0; i < ROCKPI4_UPDATABLE_IMAGES; i++) {
+   if (!guidcmp(_images[i].image_type_id, _type_guid)) {
+   fw_images[i].image_index = index;
+   break;
+   }
+   }
+}
+
+static int get_mmc_desc(struct blk_desc **desc)
+{
+  

Re: [PATCH 2/2] rockchip: rk3399: enable spl-fifo-mode for sdmmc only when needed

[Kever Yang]

On 2022/6/9 23:23, Jerome Forissier wrote:

Commit 5c606ca35c42 ("rockchip: rk3399: enable spl-fifo-mode for sdmmc")
mentions that the RK3399 SoC can't do DMA between SDMMC and SRAM.
According to the TRM "7.3.2 Embedded SRAM access path" [1], only the
8KB SRAM at 0xff3b (INTMEM1) is in this situation. The 192KB SRAM
can be accessed by both DMA controllers.

Assuming the only use case for writing from MMC to INTMEM1 is loading
a FIT image, and with the introduction of a temporary buffer for that
purpose (CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE, which is required
anyways to ensure the destination boundaries are enforced), then
spl-fifo-mode is not needed anymore and DMA can be enabled safely.

Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
CC: Deepak Das 
Signed-off-by: Jerome Forissier 


Reviewed-by: Kever Yang 


Thanks,

- Kever


---
  arch/arm/dts/rk3399-u-boot.dtsi | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 716b9a433a..a1b6d6f007 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -124,8 +124,10 @@
   {
u-boot,dm-pre-reloc;
  
+#ifndef CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE

/* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
u-boot,spl-fifo-mode;
+#endif
  };
  
   {

Re: [PATCH] rockchip: pinebook-pro: sync PBP dtb to 5.18

[Kever Yang]

On 2022/6/12 22:25, Peter Robinson wrote:

Sync the pinebook pro to upstream 5.18, in particular this brings
brings in a fix so the DP is disabled so Linux will actually boot.

Signed-off-by: Peter Robinson 


Reviewed-by: Kever Yang 


Thanks,

- Kever


---
  arch/arm/dts/rk3399-pinebook-pro.dts | 11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/rk3399-pinebook-pro.dts 
b/arch/arm/dts/rk3399-pinebook-pro.dts
index 2b5f001ff4a..d6b68d77d63 100644
--- a/arch/arm/dts/rk3399-pinebook-pro.dts
+++ b/arch/arm/dts/rk3399-pinebook-pro.dts
@@ -17,6 +17,7 @@
  / {
model = "Pine64 Pinebook Pro";
compatible = "pine64,pinebook-pro", "rockchip,rk3399";
+   chassis-type = "laptop";
  
  	aliases {

mmc0 = 
@@ -242,12 +243,12 @@
vdd_log: vdd-log {
compatible = "pwm-regulator";
pwms = < 0 25000 1>;
+   pwm-supply = <_sysin>;
regulator-name = "vdd_log";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
-   vin-supply = <_sysin>;
  
  		regulator-state-mem {

regulator-on-in-suspend;
@@ -385,10 +386,6 @@
};
  };
  
-_dp {

-   status = "okay";
-};
-
  _b0 {
cpu-supply = <_cpu_b>;
  };
@@ -475,8 +472,6 @@
vcc10-supply = <_sysin>;
vcc11-supply = <_sysin>;
vcc12-supply = <_sys>;
-   vcc13-supply = <_sysin>;
-   vcc14-supply = <_sysin>;
  
  		regulators {

/* rk3399 center logic supply */
@@ -711,7 +706,7 @@
  
  		connector {

compatible = "usb-c-connector";
-   data-role = "host";
+   data-role = "dual";
label = "USB-C";
op-sink-microwatt = <100>;
power-role = "dual";

Re: [PATCH] rockchip: rockpro64: enable leds

[Kever Yang]

On 2022/6/12 21:52, Peter Robinson wrote:

The Rockpro64 has some GPIO leds so let's enable them so the
user gets some output in early boot.

Signed-off-by: Peter Robinson 


Reviewed-by: Kever Yang 


Thanks,

- Kever


---
  configs/rockpro64-rk3399_defconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/configs/rockpro64-rk3399_defconfig 
b/configs/rockpro64-rk3399_defconfig
index e6f7a8469a3..b0c3527fab0 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -42,6 +42,8 @@ CONFIG_AHCI_PCI=y
  CONFIG_SATA_SIL=y
  CONFIG_ROCKCHIP_GPIO=y
  CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
  CONFIG_MISC=y
  CONFIG_ROCKCHIP_EFUSE=y
  CONFIG_MMC_DW=y

Re: [PATCH] rockchip: pinebook-pro: minor SPI flash fixes

[Kever Yang]

On 2022/6/12 21:47, Peter Robinson wrote:

Set a default offset for environment so it doesn't write it to
unexpected locations, drop unneeded mtd config option.

Signed-off-by: Peter Robinson 


Reviewed-by: Kever Yang 


Thanks,

- Kever


---
  configs/pinebook-pro-rk3399_defconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/pinebook-pro-rk3399_defconfig 
b/configs/pinebook-pro-rk3399_defconfig
index 8ca1d0708f9..aaa52c6ea70 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -5,6 +5,7 @@ CONFIG_ARCH_ROCKCHIP=y
  CONFIG_SYS_TEXT_BASE=0x0020
  CONFIG_NR_DRAM_BANKS=1
  CONFIG_ENV_SIZE=0x8000
+CONFIG_ENV_OFFSET=0x3F8000
  CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro"
  CONFIG_ROCKCHIP_RK3399=y
  CONFIG_TARGET_PINEBOOK_PRO_RK3399=y
@@ -22,7 +23,6 @@ CONFIG_MISC_INIT_R=y
  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
  CONFIG_SPL_STACK_R=y
  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
-CONFIG_SPL_MTD_SUPPORT=y
  CONFIG_SPL_SPI_LOAD=y
  CONFIG_TPL=y
  CONFIG_CMD_BOOTZ=y

Re: [PATCH 0/8] u-boot: fs: add generic unaligned read handling

[Qu Wenruo]

On 2022/6/28 22:17, Tom Rini wrote:

On Tue, Jun 28, 2022 at 03:28:00PM +0800, Qu Wenruo wrote:

[BACKGROUND]
Unlike FUSE/Kernel which always pass aligned read range, U-boot fs code
just pass the request range to underlying fses.

Under most case, this works fine, as U-boot only really needs to read
the whole file (aka, 0 for both offset and len, len will be later
determined using file size).

But if some advanced user/script wants to extract kernel/initramfs from
combined image, we may need to do unaligned read in that case.

[ADVANTAGE]
This patchset will handle unaligned read range in _fs_read():

- Get blocksize of the underlying fs

- Read the leading block contianing the unaligned range
   The full block will be stored in a local buffer, then only copy
   the bytes in the unaligned range into the destination buffer.

   If the first block covers the whole range, we just call it aday.

- Read the aligned range if there is any

- Read the tailing block containing the unaligned range
   And copy the covered range into the destination.

[DISADVANTAGE]
There are mainly two problems:

- Extra memory allocation for every _fs_read() call
   For the leading and tailing block.

- Extra path resolving
   All those supported fs will have to do extra path resolving up to 2
   times (one for the leading block, one for the tailing block).
   This may slow down the read.


This conceptually seems like a good thing.  Can you please post some
before/after times of reading large images from the supported
filesystems?



One thing to mention is, this change doesn't really bother large file read.

As the patchset is splitting a large read into 3 parts:

1) Leading block
2) Aligned blocks, aka the main part of a large file
3) Tailing block

Most time should still be spent on part 2), not much different than the
old code. Part 1) and Part 3) are at most 2 blocks (aka, 2 * 4KiB for
most modern large enough fses).

So I doubt it would make any difference for large file read.


Furthermore, as pointed out by Huang Jianan, currently the patchset can
not handle read on soft link correctly, thus I'd update the series to do
the split into even less parts:

1) Leading block
   For the unaligned initial block

2) Aligned blocks until the end
   The tailing block should still starts at a block aligned position,
   thus most filesystems is already handling them correctly.
   (Just a min(end, blockend) is enough for most cases already).

Anyway, I'll try to craft some benchmarking for file reads using sandbox.
But please don't expect much (or any) difference in that case.

Thanks,
Qu

Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

[Jim Liu]

Hi Marek

no, not yet.

I will add i2c otp aes sha pinctrl usb spi mmc feature to
poleg_evb_defconfig  in the last commit.

about the usb patch if you have any suggestion or need modify please
let me know.

On Tue, Jun 28, 2022 at 5:39 PM Marek Vasut  wrote:
>
> On 6/28/22 05:49, Jim Liu wrote:
> > Hi Marek
>
> Hi,
>
> > Thank you for your reminder.
> > Dell is use novuton uboot git repo now.
> > and request us upstream it.
> >
> > npcm7xx normal defconfig is poleg_evb_defconfig, so all people use
> > this config to build uboot.
> > and poleg_evb_defconfig is in uboot master now.
> >
> > I separate all the drivers to several commits,after I modify each
> > driver coding style.
> > and the poleg_evb_defconfig will be updated in the last commit
> >
> > When the upstream task is finished , Dell or others will use upstream uboot.
> >
> > If you have any suggestions please let me know.
>
> All right, one last question, was the poleg_evb_defconfig patch posted
> to enable this driver yet ?

RE: [PATCH] configs: ast2600: Move SPL bss section to DRAM space

[ChiaWei Wang]

Hi Sean,

> From: Sean Anderson 
> Sent: Tuesday, June 28, 2022 12:57 PM
> 
> Hi Chai,
> 
> On 6/28/22 12:23 AM, Joel Stanley wrote:
> > Hi Chai Wei,
> >
> > On Wed, 1 Jun 2022 at 08:21, Chia-Wei Wang
>  wrote:
> >>
> >> The commit b583348ca8c8 ("image: fit: Align hash output buffers")
> >> places the hash output buffer at the .bss section. However, AST2600
> >> by default executes SPL in the NOR flash XIP way. This results in the
> >> hash output cannot be written to the buffer as it is located at the R/X 
> >> only
> region.
> >>
> >> We need to move the .bss section out of the SPL body to the DRAM
> >> space, where hash output can be written to. This patch includes:
> >>   - Define the .bss section base and size
> >>   - A new SPL linker script is added with a separate .bss region specified
> >>   - Enable CONFIG_SPL_SEPARATE_BSS kconfig option
> >>
> >> Signed-off-by: Chia-Wei Wang 
> >
> > This patch breaks booting for me.
> 
> Does the patch Joel posted [1] fix your issue? It seems like I used the wrong
> macro in the first place, so hopefully this patch shouldn't be necessary.
> 
> --Sean
> 
> [1] https://lore.kernel.org/u-boot/20220620070117.3443066-1-j...@jms.id.au/

Yes. Joel's patch also solved that issue.

Relocating .bss to DRAM space can avoid similar issues.
But it do create additional maintenance work.

Chiawei

RE: [PATCH] configs: ast2600: Move SPL bss section to DRAM space

[ChiaWei Wang]

Hi Joel,

> From: Joel Stanley 
> Sent: Tuesday, June 28, 2022 12:24 PM
> 
> Hi Chai Wei,
> 
> On Wed, 1 Jun 2022 at 08:21, Chia-Wei Wang
>  wrote:
> >
> > The commit b583348ca8c8 ("image: fit: Align hash output buffers")
> > places the hash output buffer at the .bss section. However, AST2600 by
> > default executes SPL in the NOR flash XIP way. This results in the
> > hash output cannot be written to the buffer as it is located at the R/X only
> region.
> >
> > We need to move the .bss section out of the SPL body to the DRAM
> > space, where hash output can be written to. This patch includes:
> >  - Define the .bss section base and size
> >  - A new SPL linker script is added with a separate .bss region
> > specified
> >  - Enable CONFIG_SPL_SEPARATE_BSS kconfig option
> >
> > Signed-off-by: Chia-Wei Wang 
> 
> This patch breaks booting for me.
> 
> My concern with the approach is it creates extra maintenance work.
> When changes are made to the main linker script they need to be mirrored
> here, or else the aspeed port will miss out. (Having the machine tested in CI
> will help this somewhat, but only for the code paths we can test under
> emulation).

The patch was trying to solve the hash buffer allocation change to common code 
and to avoid similar issues.
But I agree there is additional maintenance work on the customized linker 
script.

> 
> I know the patch has been merged, but I have a few questions:
> 
> I imagine the ast2600 is not the only board that runs XIP. How do other boards
> solve the problem?
> 
> What happens when a symbol that is used before DRAM training has
> completed is placed in bss?

Honestly, I am not sure how other platforms/boards dealing with this.
But like U-Boot REAME stated, the initial global data is read-only.
I guess we have to be careful about the global variable use before DRAM 
initialization or even variable relocation.

> 
> How do you plan to support systems that don't have NOR?

We would like to have another defconfig for eMMC booting.
If the NOR-based linker script is not applicable, the default one can be used.

Chiawei

Re: [PATCH v2] fs/squashfs: Use kcalloc when relevant

[Tom Rini]

On Mon, Jun 27, 2022 at 12:20:03PM +0200, Miquel Raynal wrote:

> A crafted squashfs image could embed a huge number of empty metadata
> blocks in order to make the amount of malloc()'d memory overflow and be
> much smaller than expected. Because of this flaw, any random code
> positioned at the right location in the squashfs image could be memcpy'd
> from the squashfs structures into U-Boot code location while trying to
> access the rearmost blocks, before being executed.
> 
> In order to prevent this vulnerability from being exploited in eg. a
> secure boot environment, let's add a check over the amount of data
> that is going to be allocated. Such a check could look like:
> 
> if (!elem_size || n > SIZE_MAX / elem_size)
>   return NULL;
> 
> The right way to do it would be to enhance the calloc() implementation
> but this is quite an impacting change for such a small fix. Another
> solution would be to add the check before the malloc call in the
> squashfs implementation, but this does not look right. So for now, let's
> use the kcalloc() compatibility function from Linux, which has this
> check.
> 
> Fixes: c5100613037 ("fs/squashfs: new filesystem")
> Reported-by: Tatsuhiko Yasumatsu 
> Signed-off-by: Miquel Raynal 
> Tested-by: Tatsuhiko Yasumatsu 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RESEND PATCH 4/4] configs: imx8mn_bsh_smm_s2: add mtdparts to bootargs

[Tom Rini]

On Sun, Jun 26, 2022 at 12:05:18PM +0200, Dario Binacchi wrote:

> Passing the mtdparts environment variable to the Linux kernel is
> required to properly mount the UBI rootfs.
> 
> Co-developed-by: Michael Trimarchi 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RESEND PATCH 3/4] configs: imx8mn_bsh_smm_s2: remove console from bootargs

[Tom Rini]

On Sun, Jun 26, 2022 at 12:05:17PM +0200, Dario Binacchi wrote:

> The Linux kernel device tree already specifies the device to be used for
> boot console output with a stdout-path property under /chosen.
> 
> Co-developed-by: Michael Trimarchi 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RESEND PATCH 2/4] configs: imx8mn_bsh_smm_s2: add UBI commands

[Tom Rini]

On Sun, Jun 26, 2022 at 12:05:16PM +0200, Dario Binacchi wrote:

> imx8mn_bsh_smm_s2 uses ubifs rootfs, UBI commands are required to flash
> it.
> 
> Co-developed-by: Michael Trimarchi 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RESEND PATCH 1/4] configs: imx8mn_bsh_smm_s2: add NAND driver

[Tom Rini]

On Sun, Jun 26, 2022 at 12:05:15PM +0200, Dario Binacchi wrote:

> It allows to boot from NAND.
> 
> Co-developed-by: Michael Trimarchi 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] i2c: fix stack buffer overflow vulnerability in i2c md command

[Tom Rini]

On Fri, Jun 10, 2022 at 02:50:25PM +, nicolas.iooss.led...@proton.me wrote:

> From: Nicolas Iooss 
> 
> When running "i2c md 0 0 8100", the function do_i2c_md parses the
> length into an unsigned int variable named length. The value is then
> moved to a signed variable:
> 
> int nbytes = length;
> #define DISP_LINE_LEN 16
> int linebytes = (nbytes > DISP_LINE_LEN) ? DISP_LINE_LEN : nbytes;
> ret = dm_i2c_read(dev, addr, linebuf, linebytes);
> 
> On systems where integers are 32 bits wide, 0x8100 is a negative
> value to "nbytes > DISP_LINE_LEN" is false and linebytes gets assigned
> 0x8100 instead of 16.
> 
> The consequence is that the function which reads from the i2c device
> (dm_i2c_read or i2c_read) is called with a 16-byte stack buffer to fill
> but with a size parameter which is too large. In some cases, this could
> trigger a crash. But with some i2c drivers, such as drivers/i2c/nx_i2c.c
> (used with "nexell,s5pxx18-i2c" bus), the size is actually truncated to
> a 16-bit integer. This is because function i2c_transfer expects an
> unsigned short length. In such a case, an attacker who can control the
> response of an i2c device can overwrite the return address of a function
> and execute arbitrary code through Return-Oriented Programming.
> 
> Fix this issue by using unsigned integers types in do_i2c_md. While at
> it, make also alen unsigned, as signed sizes can cause vulnerabilities
> when people forgot to check that they can be negative.
> 
> Signed-off-by: Nicolas Iooss 
> Reviewed-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: 回复: minor regression in U-Boot 2022.04

[Daniel Golle]

Hi Weijie,

On Tue, Apr 12, 2022 at 01:40:00AM +, Weijie Gao (高惟杰) wrote:
> Hi Daniel,
> 
> I've also noticed this error message.
> It seems that some struct variables containing all zero data of the pinctrl 
> driver are not set to const, which causes these variables to be put into .bss 
> section, instead of .rodata section.
> As you know the .bss section does not exist in board_init_f stage, and its 
> place is overlapped by dtb used by u-boot. This will result in incorrect data 
> used by the pinctrl driver.
> 
> I'll try to fix it later.

Any news about the gobbled serial output issue?
It would be nice to update uboot-mediatek in OpenWrt to v2022.04, so
MT798x patches will easily apply on top.

Cheers

Daniel


> 
> Best Regards
> 
> Weijie
> 
> -邮件原件-
> 发件人: Daniel Golle  
> 发送时间: 2022年4月12日 6:44
> 收件人: u-boot@lists.denx.de; Weijie Gao (高惟杰) 
> 主题: minor regression in U-Boot 2022.04
> 
> Hi!
> 
> I'm about to bump the U-Boot build for MediaTek MT7622 boards in OpenWrt to 
> U-Boot 2022.04. While practially everything seems to work fine, I've noticed 
> an error message early in the serial output which was not present in U-Boot 
> 2022.01. It is even followed by a bunch of random characters which are 
> different on every boot (hints to a read-out-of-bounds on uninitialzed memory 
> or the like):
> serial_mtk serial@11002000: pinctrl_select_state_full: 
> uclass_get_device_by_phandle_id: err=-19 CC 
> 
> At another boot:
> serial_mtk serial@11002000: pinctrl_select_state_full: 
> uclass_get_device_by_phandle_id: err=-19  H H UI  $ 
> 1.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 +)
> 
> This is probably related to recent changes in dm and pinctrl, as there 
> haven't been any changes to mtk_serial itself.
> 
> Log including ROM and ARM Trusted Firmware A serial output:
> 
> F0: 102B 
> F6:  
> V0:   [0001]
> 00:  
> BP: 0400 0041 []
> G0: 1190 
> T0:  02AD [000F]
> Jump to BL
> 
> NOTICE:  BL2: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 (mt7622-snand-2ddr)
> NOTICE:  BL2: Built : 12:03:10, Apr 11 2022
> NOTICE:  SPI-NAND: W25N01GV (128MB)
> NOTICE:  BL2: Booting BL31
> NOTICE:  BL31: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 
> (mt7622-snand-2ddr)
> NOTICE:  BL31: Built : 12:03:10, Apr 11 2022 serial_mtk serial@11002000: 
> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 CC  
> U-Boot 2022.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 +)
> 
> CPU:   MediaTek MT7622
> Model: mt7622-bpi-r64
> DRAM:  1 GiB
> Core:  55 devices, 18 uclasses, devicetree: separate
> MMC:   mmc@1123: 0, mmc@1124: 1
> Loading Environment from UBI... SPI-NAND: W25N01GV (128MB) ...
> 
> 
> I will most likely not investigate this any further, but thought it might be 
> good to let you know.
> 
> 
> Best regards
> 
> 
> Daniel

[PATCH v4 2/3] usb: add isp1760 family driver

[Rui Miguel Silva]

ISP1760/61/63 are a family of usb controllers, here the main
goal is to support the ISP1763 hcd part found in the MPS3 FPGA
board form Arm. This is based on the kernel driver and ported
to u-boot.

Signed-off-by: Rui Miguel Silva 
---
 Makefile|1 +
 drivers/usb/Kconfig |2 +
 drivers/usb/common/Makefile |1 +
 drivers/usb/isp1760/Kconfig |   12 +
 drivers/usb/isp1760/Makefile|6 +
 drivers/usb/isp1760/isp1760-core.c  |  380 
 drivers/usb/isp1760/isp1760-core.h  |   96 ++
 drivers/usb/isp1760/isp1760-hcd.c   | 2477 +++
 drivers/usb/isp1760/isp1760-hcd.h   |   81 +
 drivers/usb/isp1760/isp1760-if.c|  125 ++
 drivers/usb/isp1760/isp1760-regs.h  |  292 
 drivers/usb/isp1760/isp1760-uboot.c |   75 +
 drivers/usb/isp1760/isp1760-uboot.h |   27 +
 13 files changed, 3575 insertions(+)
 create mode 100644 drivers/usb/isp1760/Kconfig
 create mode 100644 drivers/usb/isp1760/Makefile
 create mode 100644 drivers/usb/isp1760/isp1760-core.c
 create mode 100644 drivers/usb/isp1760/isp1760-core.h
 create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
 create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
 create mode 100644 drivers/usb/isp1760/isp1760-if.c
 create mode 100644 drivers/usb/isp1760/isp1760-regs.h
 create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
 create mode 100644 drivers/usb/isp1760/isp1760-uboot.h

diff --git a/Makefile b/Makefile
index 9575d43683a2..9c13c8a79f1d 100644
--- a/Makefile
+++ b/Makefile
@@ -841,6 +841,7 @@ libs-y += drivers/usb/host/
 libs-y += drivers/usb/mtu3/
 libs-y += drivers/usb/musb/
 libs-y += drivers/usb/musb-new/
+libs-y += drivers/usb/isp1760/
 libs-y += drivers/usb/phy/
 libs-y += drivers/usb/ulpi/
 ifdef CONFIG_POST
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ab1d061bd0d5..86804166de3e 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -68,6 +68,8 @@ config SPL_DM_USB_GADGET
 
 source "drivers/usb/host/Kconfig"
 
+source "drivers/usb/isp1760/Kconfig"
+
 source "drivers/usb/cdns3/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index dc05cb0a5077..f08b064d2493 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,6 +4,7 @@
 #
 
 obj-$(CONFIG_$(SPL_)DM_USB) += common.o
+obj-$(CONFIG_USB_ISP1760) += usb_urb.o
 obj-$(CONFIG_USB_MUSB_HCD) += usb_urb.o
 obj-$(CONFIG_USB_MUSB_UDC) += usb_urb.o
 obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
diff --git a/drivers/usb/isp1760/Kconfig b/drivers/usb/isp1760/Kconfig
new file mode 100644
index ..993d71e74cd2
--- /dev/null
+++ b/drivers/usb/isp1760/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config USB_ISP1760
+   tristate "NXP ISP 1760/1761/1763 support"
+   select DM_USB
+   select USB_HOST
+   help
+ Say Y or M here if your system as an ISP1760/1761/1763 USB host
+ controller.
+
+ This USB controller is usually attached to a non-DMA-Master
+ capable bus.
diff --git a/drivers/usb/isp1760/Makefile b/drivers/usb/isp1760/Makefile
new file mode 100644
index ..2c809c01b118
--- /dev/null
+++ b/drivers/usb/isp1760/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+isp1760-y := isp1760-core.o isp1760-if.o isp1760-uboot.o isp1760-hcd.o
+
+#isp1760-hcd.o
+
+obj-$(CONFIG_USB_ISP1760) += isp1760.o
diff --git a/drivers/usb/isp1760/isp1760-core.c 
b/drivers/usb/isp1760/isp1760-core.c
new file mode 100644
index ..31dfdae6c995
--- /dev/null
+++ b/drivers/usb/isp1760/isp1760-core.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the NXP ISP1760 chip
+ *
+ * Copyright 2022 Linaro, Rui Miguel Silva 
+ *
+ * This is based on linux kernel driver, original developed:
+ * Copyright 2014 Laurent Pinchart
+ * Copyright 2007 Sebastian Siewior
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "isp1760-core.h"
+#include "isp1760-hcd.h"
+#include "isp1760-regs.h"
+
+#define msleep(a) udelay((a) * 1000)
+
+static int isp1760_init_core(struct isp1760_device *isp)
+{
+   struct isp1760_hcd *hcd = >hcd;
+
+   /*
+* Reset the host controller, including the CPU interface
+* configuration.
+*/
+   isp1760_field_set(hcd->fields, SW_RESET_RESET_ALL);
+   msleep(100);
+
+   /* Setup HW Mode Control: This assumes a level active-low interrupt */
+   if ((isp->devflags & ISP1760_FLAG_ANALOG_OC) && hcd->is_isp1763)
+   return -EINVAL;
+
+   if (isp->devflags & ISP1760_FLAG_BUS_WIDTH_16)
+   isp1760_field_clear(hcd->fields, HW_DATA_BUS_WIDTH);
+   if (isp->devflags & ISP1760_FLAG_BUS_WIDTH_8)
+   isp1760_field_set(hcd->fields, HW_DATA_BUS_WIDTH);
+   if (isp->devflags & ISP1760_FLAG_ANALOG_OC)
+   

Serial console input dead after successfully booting buildroot system on rpi4

[Matthias]

Hi,

after using the u-boot (v2022.01) bootloader built with rpi_4_32b_defconfig on 
a buildroot 2022.05 custom system, I can no longer input on the serial console 
connected to an FTDI adapter wired to Pins 8/10 of the RPi4 GPIO pin header.

Here's what I did:

* Replaced kernel=zImage by kernel=u-boot.bin in config.txt
* Copied u-boot.bin to the boot partition
* On the u-boot prompt:
  u-boot> fatload mmc 0:1 ${kernel_addr_r} zImage
  u-boot> fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
  u-boot> setenv bootargs console=tty1 console=ttyAMA0,115200 
root=/dev/mmcblk0p2 rootwait
  u-boot> bootz ${kernel_addr_r} - ${fdt_addr_r}

The system boots up fine and is fully functional. Messages keep getting printed 
to the serial console but no input is received, e.g. login is not possible. 
Logging on via SSH works fine. When starting up the system by means of 
kernel=zImage directly the problem does not occur.

Any idea what might be the reason?

Re: [PATCH v4 3/3] corstone1000: enable isp1763 usb controller and mmc

[Rui Miguel Silva]

Hi Marek,
On Tue, Jun 28, 2022 at 09:05:43PM +0200, Marek Vasut wrote:
> On 6/28/22 19:42, Rui Miguel Silva wrote:
> > MPS3 board have a ISP1763 usb controller, enable it to be used
> > for mass storage access for example. Enable the usb command
> > also and for the FVP support for mass storage enable the mmc
> > command.
> 
> This one does not apply to u-boot/master , do you have some other patch
> somewhere ? I applied the first two to usb/next in the meantime.

This applies to u-boot/next. Where Tom already applied the corstone1000
platform support.

Cheers,
   Rui

Re: [PATCH 2/2] pmic: pca9450: clear PRESET_EN bit for BUCK1/2/3 voltage settings

[Marek Vasut]

On 6/28/22 22:02, Fabio Estevam wrote:

On 28/06/2022 11:06, Heiko Thiery wrote:

The regulator driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to
set the voltage for the buck regulators 1, 2 and 3. This has no effect 
as the

PRESET_EN bit is set by default and therefore the preset values are used
instead, which are set to 850 mV.

This is a port of the same change in the Linux kernel:
98b94b6e38ca0 ("regulator: pca9450: Clear PRESET_EN bit to fix
BUCK1/2/3 voltage setting")

Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 
---
 drivers/power/pmic/pca9450.c | 6 ++
 include/power/pca9450.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index fecab0496f..1c59362ab4 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -94,6 +94,12 @@ static int pca9450_probe(struct udevice *dev)

 priv->regmap = syscon_node_to_regmap(dev_ofnode(dev));

+    /* Clear PRESET_EN bit in BUCK123_DVS to use DVS registers */
+    if (CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
+    ret = regmap_update_bits(priv->regmap, PCA9450_BUCK123_DVS,
+ BUCK123_PRESET_EN, 0);
+    }


Nit: the braces could be dropped.


IIRC they were recommended on multi-line code in conditional. I think 
checkpatch --strict might even warn about them missing.

Re: [PATCH 2/2] pmic: pca9450: clear PRESET_EN bit for BUCK1/2/3 voltage settings

[Fabio Estevam]

On 28/06/2022 11:06, Heiko Thiery wrote:
The regulator driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 
to
set the voltage for the buck regulators 1, 2 and 3. This has no effect 
as the
PRESET_EN bit is set by default and therefore the preset values are 
used

instead, which are set to 850 mV.

This is a port of the same change in the Linux kernel:
98b94b6e38ca0 ("regulator: pca9450: Clear PRESET_EN bit to fix
BUCK1/2/3 voltage setting")

Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 
---
 drivers/power/pmic/pca9450.c | 6 ++
 include/power/pca9450.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c 
b/drivers/power/pmic/pca9450.c

index fecab0496f..1c59362ab4 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -94,6 +94,12 @@ static int pca9450_probe(struct udevice *dev)

priv->regmap = syscon_node_to_regmap(dev_ofnode(dev));

+   /* Clear PRESET_EN bit in BUCK123_DVS to use DVS registers */
+   if (CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
+   ret = regmap_update_bits(priv->regmap, PCA9450_BUCK123_DVS,
+BUCK123_PRESET_EN, 0);
+   }


Nit: the braces could be dropped.

Reviewed-by: Fabio Estevam 

Re: [PATCH 1/2] pmic: pca9450: enable system reset on WDOG_B assertion

[Fabio Estevam]

On 28/06/2022 11:06, Heiko Thiery wrote:

By default the PCA9450 doesn't handle the assertion of the WDOG_B
signal, but this is required to guarantee that things like software
resets triggered by the watchdog work reliably.

This is a port of the same changes in the Linux kernel:
f7684f5a048f ("regulator: pca9450: Enable system reset on WDOG_B 
assertion")
2364a64d0673 ("regulator: pca9450: Make warm reset on WDOG_B 
assertion")


Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 


Reviewed-by: Fabio Estevam 

Re: Pull request: u-boot-imx u-boot-imx-20220628

[Tom Rini]

On Tue, Jun 28, 2022 at 05:08:12PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> last i.MX's fixes for the release.
> 
> 
> The following changes since commit bfa9306e140c136e43d0efc9574991db46ad8c9e:
> 
>   Merge branch 'master' of
> https://source.denx.de/u-boot/custodians/u-boot-sunxi (2022-06-26 21:06:08
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
> tags/u-boot-imx-20220628
> 
> for you to fetch changes up to b5023254b88a67fcbca913e212e3401dea521fc9:
> 
>   kontron-sl-mx8mm: Add CAAM support (2022-06-28 15:24:31 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

On Tuesday 28 June 2022 15:08:57 Tom Rini wrote:
> On Tue, Jun 28, 2022 at 08:58:48PM +0200, Pali Rohár wrote:
> > On Tuesday 28 June 2022 14:53:26 Tom Rini wrote:
> > > On Tue, Jun 28, 2022 at 08:41:44PM +0200, Pali Rohár wrote:
> > > > On Tuesday 28 June 2022 14:39:11 Tom Rini wrote:
> > > > > On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> > > > > > On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > > > > > > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > > > > > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > > > > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > > > > > > 
> > > > > > > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for 
> > > > > > > > > > calculation of
> > > > > > > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, 
> > > > > > > > > > CONFIG_SYS_MMC_U_BOOT_* and
> > > > > > > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > > > > > 
> > > > > > > > > > No functional change.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Pali Rohár 
> > > > > > > > > > ---
> > > > > > > > > > Changes in v2:
> > > > > > > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > > > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > > > > > > ---
> > > > > > > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > > > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > @@ -78,15 +78,15 @@
> > > > > > > > > >  
> > > > > > > > > >  #ifdef CONFIG_SDCARD
> > > > > > > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
> > > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
> > > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
> > > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
> > > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_START
> > > > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > > > > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
> > > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > > > > > > > (0x1100)
> > > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
> > > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
> > > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  
> > > > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   
> > > > > > > > > > CONFIG_SPL_PAD_TO
> > > > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > > > > > > >  #ifdef CONFIG_TPL_BUILD
> > > > > > > > > 
> > > > > > > > > So, this is entirely a PowerPC spl set of CONFIG variables.  
> > > > > > > > > Can we move
> > > > > > > > > them to Kconfig, and use default xxx as you're changing them 
> > > > > > > > > to above?
> > > > > > > > > The other platforms using this look to be doing the same at 
> > > > > > > > > first
> > > > > > > > > glance.
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > Tom
> > > > > > > > 
> > > > > > > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS 
> > > > > > > > would need
> > > > > > > > to be adjusted by size of boot sector, as is in this patch:
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > > > > > > 
> > > > > > > > So I just sent patch in current form which simplify definitions 
> > > > > > > > of
> > > > > > > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* 
> > > > > > > > macros.
> > > > > > > 
> > > > > > > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two 
> > > > > > > spots,
> > > > > > > one file), remove it from CONFIG space, make it file local, and
> > > > > > > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  
> > > > > > > I'm
> > > > > > > taking a harder look at what CONFIG_SYS_* can be moved to 
> > > > > > > Kconfig, and
> > > > > > > what needs to be just something else, and what can be cleaned up /
> > > > > > > removed, so I really want to figure out a solution here that 
> > > > > > > migrates
> > > > > > > the symbols or removes them from CONFIG namespace.
> > > > > > > 
> > > > > > > -- 
> > > > > > > Tom
> > > > > > 
> > > > > > More than month ago I 

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Tom Rini]

On Tue, Jun 28, 2022 at 08:58:48PM +0200, Pali Rohár wrote:
> On Tuesday 28 June 2022 14:53:26 Tom Rini wrote:
> > On Tue, Jun 28, 2022 at 08:41:44PM +0200, Pali Rohár wrote:
> > > On Tuesday 28 June 2022 14:39:11 Tom Rini wrote:
> > > > On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> > > > > On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > > > > > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > > > > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > > > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > > > > > 
> > > > > > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for 
> > > > > > > > > calculation of
> > > > > > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, 
> > > > > > > > > CONFIG_SYS_MMC_U_BOOT_* and
> > > > > > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > > > > 
> > > > > > > > > No functional change.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Pali Rohár 
> > > > > > > > > ---
> > > > > > > > > Changes in v2:
> > > > > > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > > > > > ---
> > > > > > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > @@ -78,15 +78,15 @@
> > > > > > > > >  
> > > > > > > > >  #ifdef CONFIG_SDCARD
> > > > > > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE   (768 << 10)
> > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST(0x1100)
> > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_START  (0x1100)
> > > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS   (128 << 10)
> > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > > > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE (768 << 10)
> > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  
> > > > > > > > > (0x1100)
> > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START(0x1100)
> > > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS (128 << 10)
> > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  
> > > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START
> > > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS 
> > > > > > > > > CONFIG_SPL_PAD_TO
> > > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > > > > > >  #ifdef CONFIG_TPL_BUILD
> > > > > > > > 
> > > > > > > > So, this is entirely a PowerPC spl set of CONFIG variables.  
> > > > > > > > Can we move
> > > > > > > > them to Kconfig, and use default xxx as you're changing them to 
> > > > > > > > above?
> > > > > > > > The other platforms using this look to be doing the same at 
> > > > > > > > first
> > > > > > > > glance.
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Tom
> > > > > > > 
> > > > > > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would 
> > > > > > > need
> > > > > > > to be adjusted by size of boot sector, as is in this patch:
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > > > > > 
> > > > > > > So I just sent patch in current form which simplify definitions of
> > > > > > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > 
> > > > > > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two 
> > > > > > spots,
> > > > > > one file), remove it from CONFIG space, make it file local, and
> > > > > > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> > > > > > taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, 
> > > > > > and
> > > > > > what needs to be just something else, and what can be cleaned up /
> > > > > > removed, so I really want to figure out a solution here that 
> > > > > > migrates
> > > > > > the symbols or removes them from CONFIG namespace.
> > > > > > 
> > > > > > -- 
> > > > > > Tom
> > > > > 
> > > > > More than month ago I proposed different solution, prepare codebase to
> > > > > completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted 
> > > > > to
> > > > > it and now I see on patchwork just "Changes Requested".
> > > > > 

Re: [PATCH v4 3/3] corstone1000: enable isp1763 usb controller and mmc

[Marek Vasut]

On 6/28/22 19:42, Rui Miguel Silva wrote:

MPS3 board have a ISP1763 usb controller, enable it to be used
for mass storage access for example. Enable the usb command
also and for the FVP support for mass storage enable the mmc
command.


This one does not apply to u-boot/master , do you have some other patch 
somewhere ? I applied the first two to usb/next in the meantime.

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

On Tuesday 28 June 2022 14:53:26 Tom Rini wrote:
> On Tue, Jun 28, 2022 at 08:41:44PM +0200, Pali Rohár wrote:
> > On Tuesday 28 June 2022 14:39:11 Tom Rini wrote:
> > > On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> > > > On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > > > > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > > > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > > > > 
> > > > > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for 
> > > > > > > > calculation of
> > > > > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, 
> > > > > > > > CONFIG_SYS_MMC_U_BOOT_* and
> > > > > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > > > 
> > > > > > > > No functional change.
> > > > > > > > 
> > > > > > > > Signed-off-by: Pali Rohár 
> > > > > > > > ---
> > > > > > > > Changes in v2:
> > > > > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > > > > ---
> > > > > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > @@ -78,15 +78,15 @@
> > > > > > > >  
> > > > > > > >  #ifdef CONFIG_SDCARD
> > > > > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
> > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
> > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
> > > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
> > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
> > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > > > > > (0x1100)
> > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
> > > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
> > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  
> > > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   
> > > > > > > > CONFIG_SPL_PAD_TO
> > > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > > > > >  #ifdef CONFIG_TPL_BUILD
> > > > > > > 
> > > > > > > So, this is entirely a PowerPC spl set of CONFIG variables.  Can 
> > > > > > > we move
> > > > > > > them to Kconfig, and use default xxx as you're changing them to 
> > > > > > > above?
> > > > > > > The other platforms using this look to be doing the same at first
> > > > > > > glance.
> > > > > > > 
> > > > > > > -- 
> > > > > > > Tom
> > > > > > 
> > > > > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would 
> > > > > > need
> > > > > > to be adjusted by size of boot sector, as is in this patch:
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > > > > 
> > > > > > So I just sent patch in current form which simplify definitions of
> > > > > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > 
> > > > > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
> > > > > one file), remove it from CONFIG space, make it file local, and
> > > > > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> > > > > taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
> > > > > what needs to be just something else, and what can be cleaned up /
> > > > > removed, so I really want to figure out a solution here that migrates
> > > > > the symbols or removes them from CONFIG namespace.
> > > > > 
> > > > > -- 
> > > > > Tom
> > > > 
> > > > More than month ago I proposed different solution, prepare codebase to
> > > > completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted to
> > > > it and now I see on patchwork just "Changes Requested".
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-2-p...@kernel.org/
> > > 
> > > Er, I see
> > > https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-1-p...@kernel.org/
> > > notes it fails to build, so that's probably the changes requested.
> > > 
> > > -- 
> > > Tom
> > 
> > V2 for that build failure already exists and 

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Tom Rini]

On Tue, Jun 28, 2022 at 08:41:44PM +0200, Pali Rohár wrote:
> On Tuesday 28 June 2022 14:39:11 Tom Rini wrote:
> > On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> > > On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > > > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > > > 
> > > > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for 
> > > > > > > calculation of
> > > > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, 
> > > > > > > CONFIG_SYS_MMC_U_BOOT_* and
> > > > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > > 
> > > > > > > No functional change.
> > > > > > > 
> > > > > > > Signed-off-by: Pali Rohár 
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > > > ---
> > > > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > @@ -78,15 +78,15 @@
> > > > > > >  
> > > > > > >  #ifdef CONFIG_SDCARD
> > > > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE   (768 << 10)
> > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST(0x1100)
> > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_START  (0x1100)
> > > > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS   (128 << 10)
> > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE (768 << 10)
> > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  (0x1100)
> > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START(0x1100)
> > > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS (128 << 10)
> > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  
> > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START
> > > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > > > >  #ifdef CONFIG_TPL_BUILD
> > > > > > 
> > > > > > So, this is entirely a PowerPC spl set of CONFIG variables.  Can we 
> > > > > > move
> > > > > > them to Kconfig, and use default xxx as you're changing them to 
> > > > > > above?
> > > > > > The other platforms using this look to be doing the same at first
> > > > > > glance.
> > > > > > 
> > > > > > -- 
> > > > > > Tom
> > > > > 
> > > > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
> > > > > to be adjusted by size of boot sector, as is in this patch:
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > > > 
> > > > > So I just sent patch in current form which simplify definitions of
> > > > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > 
> > > > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
> > > > one file), remove it from CONFIG space, make it file local, and
> > > > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> > > > taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
> > > > what needs to be just something else, and what can be cleaned up /
> > > > removed, so I really want to figure out a solution here that migrates
> > > > the symbols or removes them from CONFIG namespace.
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > More than month ago I proposed different solution, prepare codebase to
> > > completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted to
> > > it and now I see on patchwork just "Changes Requested".
> > > https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-2-p...@kernel.org/
> > 
> > Er, I see
> > https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-1-p...@kernel.org/
> > notes it fails to build, so that's probably the changes requested.
> > 
> > -- 
> > Tom
> 
> V2 for that build failure already exists and half hour ago I sent
> another reminder for v2:
> https://lore.kernel.org/u-boot/20220628181436.iwmwvvoithgwp6pu@pali/
> but it has nothing with CONFIG_SYS_MMC_U_BOOT_OFFS...

Patch 1/3 in the series causes fails to build errors, the whole series
gets changes requested, that's normal to me and 

Re: [PATCH 4/6] legoev3: Migrate to DM_I2C

[David Lechner]

On 6/27/22 12:35 PM, Tom Rini wrote:

Perform a basic migration of the calls in setup_serial_number() to DM so
that we can switch to using DM_I2C on this platform.

Cc: David Lechner 
Signed-off-by: Tom Rini 
---


Acked-by: David Lechner 

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

On Tuesday 28 June 2022 14:39:11 Tom Rini wrote:
> On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> > On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > > 
> > > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for 
> > > > > > calculation of
> > > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, 
> > > > > > CONFIG_SYS_MMC_U_BOOT_* and
> > > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > > 
> > > > > > No functional change.
> > > > > > 
> > > > > > Signed-off-by: Pali Rohár 
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > > ---
> > > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > 
> > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > @@ -78,15 +78,15 @@
> > > > > >  
> > > > > >  #ifdef CONFIG_SDCARD
> > > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
> > > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
> > > > > > -#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
> > > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
> > > > > > +#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > > > > > +#define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
> > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x1100)
> > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
> > > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
> > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > > > CONFIG_SYS_TEXT_BASE
> > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > > >  #ifdef CONFIG_TPL_BUILD
> > > > > 
> > > > > So, this is entirely a PowerPC spl set of CONFIG variables.  Can we 
> > > > > move
> > > > > them to Kconfig, and use default xxx as you're changing them to above?
> > > > > The other platforms using this look to be doing the same at first
> > > > > glance.
> > > > > 
> > > > > -- 
> > > > > Tom
> > > > 
> > > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
> > > > to be adjusted by size of boot sector, as is in this patch:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > > 
> > > > So I just sent patch in current form which simplify definitions of
> > > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > 
> > > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
> > > one file), remove it from CONFIG space, make it file local, and
> > > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> > > taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
> > > what needs to be just something else, and what can be cleaned up /
> > > removed, so I really want to figure out a solution here that migrates
> > > the symbols or removes them from CONFIG namespace.
> > > 
> > > -- 
> > > Tom
> > 
> > More than month ago I proposed different solution, prepare codebase to
> > completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted to
> > it and now I see on patchwork just "Changes Requested".
> > https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-2-p...@kernel.org/
> 
> Er, I see
> https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-1-p...@kernel.org/
> notes it fails to build, so that's probably the changes requested.
> 
> -- 
> Tom

V2 for that build failure already exists and half hour ago I sent
another reminder for v2:
https://lore.kernel.org/u-boot/20220628181436.iwmwvvoithgwp6pu@pali/
but it has nothing with CONFIG_SYS_MMC_U_BOOT_OFFS...

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Tom Rini]

On Tue, Jun 28, 2022 at 08:34:47PM +0200, Pali Rohár wrote:
> On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> > On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > > 
> > > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation 
> > > > > of
> > > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* 
> > > > > and
> > > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > > 
> > > > > No functional change.
> > > > > 
> > > > > Signed-off-by: Pali Rohár 
> > > > > ---
> > > > > Changes in v2:
> > > > > * Rebased on top of the U-Boot next branch, commit 
> > > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > > ---
> > > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > > b/include/configs/p1_p2_rdb_pc.h
> > > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > @@ -78,15 +78,15 @@
> > > > >  
> > > > >  #ifdef CONFIG_SDCARD
> > > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE   (768 << 10)
> > > > > -#define CONFIG_SYS_MMC_U_BOOT_DST(0x1100)
> > > > > -#define CONFIG_SYS_MMC_U_BOOT_START  (0x1100)
> > > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS   (128 << 10)
> > > > > +#define CONFIG_SYS_MMC_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> > > > > +#define CONFIG_SYS_MMC_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > >  #elif defined(CONFIG_SPIFLASH)
> > > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE (768 << 10)
> > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  (0x1100)
> > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START(0x1100)
> > > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS (128 << 10)
> > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  
> > > > > CONFIG_SYS_TEXT_BASE
> > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > > >  #ifdef CONFIG_TPL_BUILD
> > > > 
> > > > So, this is entirely a PowerPC spl set of CONFIG variables.  Can we move
> > > > them to Kconfig, and use default xxx as you're changing them to above?
> > > > The other platforms using this look to be doing the same at first
> > > > glance.
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
> > > to be adjusted by size of boot sector, as is in this patch:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > > 
> > > So I just sent patch in current form which simplify definitions of
> > > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > 
> > Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
> > one file), remove it from CONFIG space, make it file local, and
> > FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> > taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
> > what needs to be just something else, and what can be cleaned up /
> > removed, so I really want to figure out a solution here that migrates
> > the symbols or removes them from CONFIG namespace.
> > 
> > -- 
> > Tom
> 
> More than month ago I proposed different solution, prepare codebase to
> completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted to
> it and now I see on patchwork just "Changes Requested".
> https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-2-p...@kernel.org/

Er, I see
https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-1-p...@kernel.org/
notes it fails to build, so that's probably the changes requested.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

On Tuesday 28 June 2022 14:28:52 Tom Rini wrote:
> On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> > On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > > 
> > > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation of
> > > > other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* 
> > > > and
> > > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > > 
> > > > No functional change.
> > > > 
> > > > Signed-off-by: Pali Rohár 
> > > > ---
> > > > Changes in v2:
> > > > * Rebased on top of the U-Boot next branch, commit 
> > > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > > ---
> > > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > > b/include/configs/p1_p2_rdb_pc.h
> > > > index 56a16502dcc7..7237e3c1a63c 100644
> > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > @@ -78,15 +78,15 @@
> > > >  
> > > >  #ifdef CONFIG_SDCARD
> > > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
> > > > -#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
> > > > -#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
> > > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
> > > > +#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > > > +#define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > >  #elif defined(CONFIG_SPIFLASH)
> > > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
> > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x1100)
> > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
> > > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
> > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST
> > > > CONFIG_SYS_TEXT_BASE
> > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > > >  #ifdef CONFIG_TPL_BUILD
> > > 
> > > So, this is entirely a PowerPC spl set of CONFIG variables.  Can we move
> > > them to Kconfig, and use default xxx as you're changing them to above?
> > > The other platforms using this look to be doing the same at first
> > > glance.
> > > 
> > > -- 
> > > Tom
> > 
> > Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
> > to be adjusted by size of boot sector, as is in this patch:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> > 
> > So I just sent patch in current form which simplify definitions of
> > CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> 
> Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
> one file), remove it from CONFIG space, make it file local, and
> FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
> taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
> what needs to be just something else, and what can be cleaned up /
> removed, so I really want to figure out a solution here that migrates
> the symbols or removes them from CONFIG namespace.
> 
> -- 
> Tom

More than month ago I proposed different solution, prepare codebase to
completely drop CONFIG_SYS_MMC_U_BOOT_OFFS option. But nobody reacted to
it and now I see on patchwork just "Changes Requested".
https://patchwork.ozlabs.org/project/uboot/patch/20220511183332.1362-2-p...@kernel.org/

So I'm not going to invest more time to CONFIG_SYS_MMC_U_BOOT_OFFS as I
see that there is no interested in it...

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Tom Rini]

On Tue, Jun 28, 2022 at 08:22:38PM +0200, Pali Rohár wrote:
> On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> > On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> > 
> > > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation of
> > > other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* and
> > > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > > 
> > > No functional change.
> > > 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > Changes in v2:
> > > * Rebased on top of the U-Boot next branch, commit 
> > > d61c11b8c894fad517677dc51ee82d1eade39c01
> > > ---
> > >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/include/configs/p1_p2_rdb_pc.h 
> > > b/include/configs/p1_p2_rdb_pc.h
> > > index 56a16502dcc7..7237e3c1a63c 100644
> > > --- a/include/configs/p1_p2_rdb_pc.h
> > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > @@ -78,15 +78,15 @@
> > >  
> > >  #ifdef CONFIG_SDCARD
> > >  #define CONFIG_SYS_MMC_U_BOOT_SIZE   (768 << 10)
> > > -#define CONFIG_SYS_MMC_U_BOOT_DST(0x1100)
> > > -#define CONFIG_SYS_MMC_U_BOOT_START  (0x1100)
> > > -#define CONFIG_SYS_MMC_U_BOOT_OFFS   (128 << 10)
> > > +#define CONFIG_SYS_MMC_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> > > +#define CONFIG_SYS_MMC_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > > +#define CONFIG_SYS_MMC_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > >  #elif defined(CONFIG_SPIFLASH)
> > >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE (768 << 10)
> > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  (0x1100)
> > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START(0x1100)
> > > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS (128 << 10)
> > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> > >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> > >  #elif defined(CONFIG_MTD_RAW_NAND)
> > >  #ifdef CONFIG_TPL_BUILD
> > 
> > So, this is entirely a PowerPC spl set of CONFIG variables.  Can we move
> > them to Kconfig, and use default xxx as you're changing them to above?
> > The other platforms using this look to be doing the same at first
> > glance.
> > 
> > -- 
> > Tom
> 
> Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
> to be adjusted by size of boot sector, as is in this patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/
> 
> So I just sent patch in current form which simplify definitions of
> CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.

Given the limited places we use CONFIG_SYS_MMC_U_BOOT_OFFS (two spots,
one file), remove it from CONFIG space, make it file local, and
FSL_PREPBL_ESDHC_BOOT_SECTOR will be in Kconfig to start with?  I'm
taking a harder look at what CONFIG_SYS_* can be moved to Kconfig, and
what needs to be just something else, and what can be cleaned up /
removed, so I really want to figure out a solution here that migrates
the symbols or removes them from CONFIG namespace.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

On Tuesday 28 June 2022 14:17:42 Tom Rini wrote:
> On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:
> 
> > Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation of
> > other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* and
> > CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> > 
> > No functional change.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> > Changes in v2:
> > * Rebased on top of the U-Boot next branch, commit 
> > d61c11b8c894fad517677dc51ee82d1eade39c01
> > ---
> >  include/configs/p1_p2_rdb_pc.h | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > index 56a16502dcc7..7237e3c1a63c 100644
> > --- a/include/configs/p1_p2_rdb_pc.h
> > +++ b/include/configs/p1_p2_rdb_pc.h
> > @@ -78,15 +78,15 @@
> >  
> >  #ifdef CONFIG_SDCARD
> >  #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
> > -#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
> > -#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
> > -#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
> > +#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> > +#define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> > +#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
> >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> >  #elif defined(CONFIG_SPIFLASH)
> >  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
> > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x1100)
> > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
> > -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
> > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> > +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
> >  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
> >  #elif defined(CONFIG_MTD_RAW_NAND)
> >  #ifdef CONFIG_TPL_BUILD
> 
> So, this is entirely a PowerPC spl set of CONFIG variables.  Can we move
> them to Kconfig, and use default xxx as you're changing them to above?
> The other platforms using this look to be doing the same at first
> glance.
> 
> -- 
> Tom

Not sure how to do it right now. CONFIG_SYS_MMC_U_BOOT_OFFS would need
to be adjusted by size of boot sector, as is in this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220405134032.704-3-p...@kernel.org/

So I just sent patch in current form which simplify definitions of
CONFIG_SYS_MMC_U_BOOT_* and CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Tom Rini]

On Tue, Jun 28, 2022 at 07:53:55PM +0200, Pali Rohár wrote:

> Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation of
> other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* and
> CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.
> 
> No functional change.
> 
> Signed-off-by: Pali Rohár 
> ---
> Changes in v2:
> * Rebased on top of the U-Boot next branch, commit 
> d61c11b8c894fad517677dc51ee82d1eade39c01
> ---
>  include/configs/p1_p2_rdb_pc.h | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> index 56a16502dcc7..7237e3c1a63c 100644
> --- a/include/configs/p1_p2_rdb_pc.h
> +++ b/include/configs/p1_p2_rdb_pc.h
> @@ -78,15 +78,15 @@
>  
>  #ifdef CONFIG_SDCARD
>  #define CONFIG_SYS_MMC_U_BOOT_SIZE   (768 << 10)
> -#define CONFIG_SYS_MMC_U_BOOT_DST(0x1100)
> -#define CONFIG_SYS_MMC_U_BOOT_START  (0x1100)
> -#define CONFIG_SYS_MMC_U_BOOT_OFFS   (128 << 10)
> +#define CONFIG_SYS_MMC_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
> +#define CONFIG_SYS_MMC_U_BOOT_START  CONFIG_SYS_TEXT_BASE
> +#define CONFIG_SYS_MMC_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
>  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
>  #elif defined(CONFIG_SPIFLASH)
>  #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE (768 << 10)
> -#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  (0x1100)
> -#define CONFIG_SYS_SPI_FLASH_U_BOOT_START(0x1100)
> -#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS (128 << 10)
> +#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
> +#define CONFIG_SYS_SPI_FLASH_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
> +#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS CONFIG_SPL_PAD_TO
>  #define CONFIG_SYS_MPC85XX_NO_RESETVEC
>  #elif defined(CONFIG_MTD_RAW_NAND)
>  #ifdef CONFIG_TPL_BUILD

So, this is entirely a PowerPC spl set of CONFIG variables.  Can we move
them to Kconfig, and use default xxx as you're changing them to above?
The other platforms using this look to be doing the same at first
glance.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] mmc: fsl_esdhc_spl: Add support for loading proper U-Boot from unaligned location

[Pali Rohár]

On Thursday 23 June 2022 15:31:14 Pali Rohár wrote:
> On Monday 20 June 2022 12:54:26 Pali Rohár wrote:
> > This allows to concatenate SPL and proper U-Boot without extra alignment.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> > Changes in v2:
> > * Rebased on top of the U-Boot next branch, commit 
> > 98c4828740f4944462b7d9608b95d5b73850c7b0
> 
> PING?

PING?

> > ---
> >  drivers/mmc/fsl_esdhc_spl.c | 27 +++
> >  1 file changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/mmc/fsl_esdhc_spl.c b/drivers/mmc/fsl_esdhc_spl.c
> > index 760f13d24018..54bf8152ca7a 100644
> > --- a/drivers/mmc/fsl_esdhc_spl.c
> > +++ b/drivers/mmc/fsl_esdhc_spl.c
> > @@ -58,10 +58,10 @@ void __noreturn mmc_boot(void)
> >  {
> > __attribute__((noreturn)) void (*uboot)(void);
> > uint blk_start, blk_cnt, err;
> > +   u32 blk_off;
> >  #ifndef CONFIG_FSL_CORENET
> > uchar *tmp_buf;
> > u32 blklen;
> > -   u32 blk_off;
> > uchar val;
> >  #ifndef CONFIG_SPL_FSL_PBL
> > u32 val32;
> > @@ -155,10 +155,21 @@ again:
> > * Load U-Boot image from mmc into RAM
> > */
> > code_len = CONFIG_SYS_MMC_U_BOOT_SIZE;
> > -   blk_start = ALIGN(offset, mmc->read_bl_len) / mmc->read_bl_len;
> > -   blk_cnt = ALIGN(code_len, mmc->read_bl_len) / mmc->read_bl_len;
> > +   blk_start = offset / mmc->read_bl_len;
> > +   blk_off = offset % mmc->read_bl_len;
> > +   blk_cnt = ALIGN(code_len, mmc->read_bl_len) / mmc->read_bl_len + 1;
> > +   if (blk_off) {
> > +   err = mmc->block_dev.block_read(>block_dev,
> > +   blk_start, 1, tmp_buf);
> > +   if (err != 1) {
> > +   puts("spl: mmc read failed!!\n");
> > +   hang();
> > +   }
> > +   blk_start++;
> > +   }
> > err = mmc->block_dev.block_read(>block_dev, blk_start, blk_cnt,
> > -   (uchar *)CONFIG_SYS_MMC_U_BOOT_DST);
> > +   (uchar *)CONFIG_SYS_MMC_U_BOOT_DST +
> > +   (blk_off ? (mmc->read_bl_len - blk_off) 
> > : 0));
> > if (err != blk_cnt) {
> > puts("spl: mmc read failed!!\n");
> >  #ifndef CONFIG_FSL_CORENET
> > @@ -166,6 +177,14 @@ again:
> >  #endif
> > hang();
> > }
> > +   /*
> > +* SDHC DMA may erase bytes at dst + bl_len - blk_off - 8
> > +* due to unaligned access. So copy leading bytes from tmp_buf
> > +* after SDHC DMA transfer.
> > +*/
> > +   if (blk_off)
> > +   memcpy((uchar *)CONFIG_SYS_MMC_U_BOOT_DST,
> > +  tmp_buf + blk_off, mmc->read_bl_len - blk_off);
> >  
> > /*
> > * Clean d-cache and invalidate i-cache, to
> > -- 
> > 2.20.1
> > 

Re: [PATCH 1/2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL eSDHC boot sector

[Tom Rini]

On Tue, Jun 28, 2022 at 08:07:48PM +0200, Pali Rohár wrote:
> On Thursday 23 June 2022 19:17:55 Pali Rohár wrote:
> > On Saturday 04 June 2022 15:02:38 Pali Rohár wrote:
> > > On Wednesday 18 May 2022 12:53:20 Pali Rohár wrote:
> > > > On Wednesday 11 May 2022 22:59:28 Pali Rohár wrote:
> > > > > On Monday 25 April 2022 14:36:14 Pali Rohár wrote:
> > > > > > On Monday 25 April 2022 05:25:34 Priyanka Jain (OSS) wrote:
> > > > > > > >-Original Message-
> > > > > > > >From: U-Boot  On Behalf Of Pali 
> > > > > > > >Rohár
> > > > > > > >Sent: Tuesday, April 5, 2022 7:11 PM
> > > > > > > >To: Priyanka Jain ; Qiang Zhao 
> > > > > > > >;
> > > > > > > >Shengzhou Liu ; Alexander Graf 
> > > > > > > >;
> > > > > > > >Bin Meng ; Wolfgang Denk ; 
> > > > > > > >Sinan
> > > > > > > >Akman 
> > > > > > > >Cc: u-boot@lists.denx.de
> > > > > > > >Subject: [PATCH 1/2] powerpc: mpc85xx: Add support for 
> > > > > > > >generating QorIQ pre-
> > > > > > > >PBL eSDHC boot sector
> > > > > > > >
> > > > > > > >QorIQ U-Boot binary for SD card booting compiled during build 
> > > > > > > >process (either u-
> > > > > > > >boot.bin or u-boot-with-spl.bin) cannot be directly loaded by 
> > > > > > > >QorIQ pre-PBL
> > > > > > > >BootROM. Compiled U-Boot binary first needs to be processed by 
> > > > > > > >Freescale
> > > > > > > >boot_format tool as described in doc/README.mpc85xx-sd-spi-boot
> > > > > > > >
> > > > > > > >BootROM requires that image on SD card must contain special boot 
> > > > > > > >sector.
> > > > > > > >Implement support for generating this special boot sector 
> > > > > > > >directly in U-Boot start
> > > > > > > >code. Boot sector needs to be at the beginning of the image, so 
> > > > > > > >when compiling
> > > > > > > >only proper U-Boot without SPL then it needs to be in proper 
> > > > > > > >U-Boot. When
> > > > > > > >compiling SPL with proper U-Boot then it needs to be only in SPL.
> > > > > > > >
> > > > > > > >Support can be enabled by a new config option
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > >Via other two additional options 
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_START and
> > > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA it is possible to tune how 
> > > > > > > >final U-Boot
> > > > > > > >image could be stored on the SD card.
> > > > > > > >
> > > > > > > >Signed-off-by: Pali Rohár 
> > > > > > > >---
> > > > > > > 
> > > > > > > Kindly rebase the series to master.
> > > > > > > 
> > > > > > > Regards
> > > > > > > Priyanka
> > > > > > 
> > > > > > Hello! Both patches still applies cleanly on master, just they 
> > > > > > depend
> > > > > > on another patch series (powerpc: mpc85xx: Fix and cleanup mpc85xx 
> > > > > > code)
> > > > > > which I mentioned in cover letter and therefore needs V2 patch of
> > > > > > "powerpc: mpc85xx: Set TEXT_BASE addresses to real base values" 
> > > > > > which I
> > > > > > sent recently.
> > > > > 
> > > > > I sent a new version v2 of this patch, see email:
> > > > > [PATCH v2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL 
> > > > > eSDHC boot sector
> > > > 
> > > > Priyanka: PING
> > > 
> > > PING?
> > 
> > PING?
> 
> PING?
> 
> V2 now and still applies cleanly on top of next branch
> https://patchwork.ozlabs.org/project/uboot/patch/20220511185731.3000-1-p...@kernel.org/
> 
> And why v2 has "Changes Requested" state in above patchwork?

Probably my mistake, put it back to new.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL eSDHC boot sector

[Pali Rohár]

On Thursday 23 June 2022 19:17:55 Pali Rohár wrote:
> On Saturday 04 June 2022 15:02:38 Pali Rohár wrote:
> > On Wednesday 18 May 2022 12:53:20 Pali Rohár wrote:
> > > On Wednesday 11 May 2022 22:59:28 Pali Rohár wrote:
> > > > On Monday 25 April 2022 14:36:14 Pali Rohár wrote:
> > > > > On Monday 25 April 2022 05:25:34 Priyanka Jain (OSS) wrote:
> > > > > > >-Original Message-
> > > > > > >From: U-Boot  On Behalf Of Pali Rohár
> > > > > > >Sent: Tuesday, April 5, 2022 7:11 PM
> > > > > > >To: Priyanka Jain ; Qiang Zhao 
> > > > > > >;
> > > > > > >Shengzhou Liu ; Alexander Graf 
> > > > > > >;
> > > > > > >Bin Meng ; Wolfgang Denk ; Sinan
> > > > > > >Akman 
> > > > > > >Cc: u-boot@lists.denx.de
> > > > > > >Subject: [PATCH 1/2] powerpc: mpc85xx: Add support for generating 
> > > > > > >QorIQ pre-
> > > > > > >PBL eSDHC boot sector
> > > > > > >
> > > > > > >QorIQ U-Boot binary for SD card booting compiled during build 
> > > > > > >process (either u-
> > > > > > >boot.bin or u-boot-with-spl.bin) cannot be directly loaded by 
> > > > > > >QorIQ pre-PBL
> > > > > > >BootROM. Compiled U-Boot binary first needs to be processed by 
> > > > > > >Freescale
> > > > > > >boot_format tool as described in doc/README.mpc85xx-sd-spi-boot
> > > > > > >
> > > > > > >BootROM requires that image on SD card must contain special boot 
> > > > > > >sector.
> > > > > > >Implement support for generating this special boot sector directly 
> > > > > > >in U-Boot start
> > > > > > >code. Boot sector needs to be at the beginning of the image, so 
> > > > > > >when compiling
> > > > > > >only proper U-Boot without SPL then it needs to be in proper 
> > > > > > >U-Boot. When
> > > > > > >compiling SPL with proper U-Boot then it needs to be only in SPL.
> > > > > > >
> > > > > > >Support can be enabled by a new config option
> > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > >Via other two additional options 
> > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_START and
> > > > > > >FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA it is possible to tune how final 
> > > > > > >U-Boot
> > > > > > >image could be stored on the SD card.
> > > > > > >
> > > > > > >Signed-off-by: Pali Rohár 
> > > > > > >---
> > > > > > 
> > > > > > Kindly rebase the series to master.
> > > > > > 
> > > > > > Regards
> > > > > > Priyanka
> > > > > 
> > > > > Hello! Both patches still applies cleanly on master, just they depend
> > > > > on another patch series (powerpc: mpc85xx: Fix and cleanup mpc85xx 
> > > > > code)
> > > > > which I mentioned in cover letter and therefore needs V2 patch of
> > > > > "powerpc: mpc85xx: Set TEXT_BASE addresses to real base values" which 
> > > > > I
> > > > > sent recently.
> > > > 
> > > > I sent a new version v2 of this patch, see email:
> > > > [PATCH v2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL 
> > > > eSDHC boot sector
> > > 
> > > Priyanka: PING
> > 
> > PING?
> 
> PING?

PING?

V2 now and still applies cleanly on top of next branch
https://patchwork.ozlabs.org/project/uboot/patch/20220511185731.3000-1-p...@kernel.org/

And why v2 has "Changes Requested" state in above patchwork?

I do not see any comment for v2 on mailing list nor on patchwork.
So what is requested from me?

[PATCH v2] board: freescale: p1_p2_rdb_pc: Simplify SPL offset macros

[Pali Rohár]

Now when CONFIG_SYS_TEXT_BASE has sane value, use it for calculation of
other SPL offset values: CONFIG_SPL_MAX_SIZE, CONFIG_SYS_MMC_U_BOOT_* and
CONFIG_SYS_SPI_FLASH_U_BOOT_* macros.

No functional change.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Rebased on top of the U-Boot next branch, commit 
d61c11b8c894fad517677dc51ee82d1eade39c01
---
 include/configs/p1_p2_rdb_pc.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index 56a16502dcc7..7237e3c1a63c 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -78,15 +78,15 @@
 
 #ifdef CONFIG_SDCARD
 #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
-#define CONFIG_SYS_MMC_U_BOOT_DST  (0x1100)
-#define CONFIG_SYS_MMC_U_BOOT_START(0x1100)
-#define CONFIG_SYS_MMC_U_BOOT_OFFS (128 << 10)
+#define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
 #define CONFIG_SYS_MPC85XX_NO_RESETVEC
 #elif defined(CONFIG_SPIFLASH)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
-#define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x1100)
-#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  (0x1100)
-#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   (128 << 10)
+#define CONFIG_SYS_SPI_FLASH_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_SPI_FLASH_U_BOOT_START  CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS   CONFIG_SPL_PAD_TO
 #define CONFIG_SYS_MPC85XX_NO_RESETVEC
 #elif defined(CONFIG_MTD_RAW_NAND)
 #ifdef CONFIG_TPL_BUILD
-- 
2.20.1

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Remove mapping for TDM-PMC card

[Pali Rohár]

On Thursday 23 June 2022 18:22:21 Pali Rohár wrote:
> From whole P1/P2 family of RDB boards is TDM-PMC card (PCI Mezzanine Card,
> Freescale PQ-MDS-T1) available only on P1021RDB and P1025RDB boards.
> 
> So address mapping for TDM-PMC card on LBC should not be enabled on any
> other P1/P2 RDB board as there is no device at that TDM-PMC address.
> 
> Support for P1021RDB and P1025RDB boards was already removed from mainline
> U-Boot in commits 6d1dd76afe85 ("board/freescale: Remove P1021RDB board
> support") and d521cece5adb ("board/freescale: Remove P1025RDB board
> support").
> 
> So do not enable TDM-PMC address mapping on remaining P1/P2 RDB boards and
> remove all macros related to TDM-PMC address mappings.
> 
> Signed-off-by: Pali Rohár 
> ---
> Changes in v2:
> * Rebase on top of next branch, commit 
> 9121478ee6f2aee381f8fe49d8997d43527d351a
> ---

PING?

>  board/freescale/p1_p2_rdb_pc/law.c | 1 -
>  board/freescale/p1_p2_rdb_pc/tlb.c | 3 ---
>  include/configs/p1_p2_rdb_pc.h | 9 -
>  scripts/config_whitelist.txt   | 4 
>  4 files changed, 17 deletions(-)
> 
> diff --git a/board/freescale/p1_p2_rdb_pc/law.c 
> b/board/freescale/p1_p2_rdb_pc/law.c
> index 5f4d713ca569..6bdfb356eede 100644
> --- a/board/freescale/p1_p2_rdb_pc/law.c
> +++ b/board/freescale/p1_p2_rdb_pc/law.c
> @@ -9,7 +9,6 @@
>  
>  struct law_entry law_table[] = {
>   SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
> - SET_LAW(CONFIG_SYS_PMC_BASE_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_LBC),
>  #ifdef CONFIG_VSC7385_ENET
>   SET_LAW(CONFIG_SYS_VSC7385_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
>  #endif
> diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
> b/board/freescale/p1_p2_rdb_pc/tlb.c
> index 6ded38ac683e..38843a96cbfb 100644
> --- a/board/freescale/p1_p2_rdb_pc/tlb.c
> +++ b/board/freescale/p1_p2_rdb_pc/tlb.c
> @@ -65,9 +65,6 @@ struct fsl_e_tlb_entry tlb_table[] = {
>   SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,
>   MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
>   0, 6, BOOKE_PAGESZ_1M, 1),
> - SET_TLB_ENTRY(1, CONFIG_SYS_PMC_BASE, CONFIG_SYS_PMC_BASE_PHYS,
> - MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> - 0, 10, BOOKE_PAGESZ_64K, 1),
>  #endif /* not SPL */
>  
>  #ifdef CONFIG_SYS_NAND_BASE
> diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> index 56a16502dcc7..f95a77b7ed32 100644
> --- a/include/configs/p1_p2_rdb_pc.h
> +++ b/include/configs/p1_p2_rdb_pc.h
> @@ -182,7 +182,6 @@
>   * 0xf8f8_ 0xf8ff_   L2 SRAM Up to 512K cacheable
>   *   (early boot only)
>   * 0xff80_ 0xff80_7fff   NAND flash  32K non-cacheable   CS1/0
> - * 0xff98_ 0xff98_   PMC 64K non-cacheable   CS2
>   * 0xffa0_ 0xffaf_   CPLD1M non-cacheableCS3
>   * 0xffb0_ 0xffbf_   VSC7385 switch  1M non-cacheableCS2
>   * 0xffc0_ 0xffc3_   PCI IO range256k non-cacheable
> @@ -289,14 +288,6 @@
>  #endif
>  /* CPLD config size: 1Mb */
>  
> -#define CONFIG_SYS_PMC_BASE  0xff98
> -#define CONFIG_SYS_PMC_BASE_PHYS CONFIG_SYS_PMC_BASE
> -#define CONFIG_PMC_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_PMC_BASE_PHYS) | \
> - BR_PS_8 | BR_V)
> -#define CONFIG_PMC_OR_PRELIM (OR_AM_64KB | OR_GPCM_CSNT | OR_GPCM_XACS | \
> -  OR_GPCM_SCY | OR_GPCM_TRLX | OR_GPCM_EHTR | \
> -  OR_GPCM_EAD)
> -
>  /* Vsc7385 switch */
>  #ifdef CONFIG_VSC7385_ENET
>  #define __VSCFW_ADDR "vscfw_addr=ef00\0"
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 726973b26e21..7fed8b612bd7 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -456,8 +456,6 @@ CONFIG_PHY_IRAM_BASE
>  CONFIG_PL011_CLOCK
>  CONFIG_PL01x_PORTS
>  CONFIG_PM
> -CONFIG_PMC_BR_PRELIM
> -CONFIG_PMC_OR_PRELIM
>  CONFIG_PME_PLAT_CLK_DIV
>  CONFIG_POST
>  CONFIG_POSTBOOTMENU
> @@ -1465,8 +1463,6 @@ CONFIG_SYS_PLL_FDR
>  CONFIG_SYS_PLL_ODR
>  CONFIG_SYS_PLL_SETTLING_TIME
>  CONFIG_SYS_PMAN
> -CONFIG_SYS_PMC_BASE
> -CONFIG_SYS_PMC_BASE_PHYS
>  CONFIG_SYS_PME_CLK
>  CONFIG_SYS_POST_MEMORY
>  CONFIG_SYS_POST_MEM_REGIONS
> -- 
> 2.20.1
> 

Re: [PATCH v3] powerpc: mpc85xx: Set TEXT_BASE addresses to real base values

[Pali Rohár]

On Tuesday 28 June 2022 10:52:23 Tom Rini wrote:
> On Thu, Jun 16, 2022 at 02:19:44PM +0200, Pali Rohár wrote:
> 
> > Currently CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE addresses are
> > manually increased by 0x1000 due to .bootpg section. This section has size
> > of 0x1000 bytes and is manually put by linker script before .text section
> > (and therefore before base address) when CONFIG_SYS_MPC85XX_NO_RESETVEC is
> > set. Due to this fact lot of other config options are manually increased by
> > 0x1000 value to make correct layout. Note that entry point is not on
> > CONFIG_SPL_TEXT_BASE (image+0x1000) but it is really on address
> > CONFIG_SPL_TEXT_BASE-0x1000 (means at the start of the image).
> > 
> > Cleanup handling of .bootpg section when CONFIG_SYS_MPC85XX_NO_RESETVEC is
> > set. Put .bootpg code directly into .text section and move text base
> > address to the start of .bootpg code. And finally remove +0x1000 value from
> > lot of config options. With this removal custom PHDRS is not used anymore,
> > so remove it too.
> > 
> > After this change entry point would be at CONFIG_SPL_TEXT_BASE and not at
> > address -0x1000 anymore.
> > 
> > Tested on P2020 board with SPL and proper U-Boot.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Applied to u-boot/next, thanks!
> 
> -- 
> Tom

Thanks!

[PATCH v4 3/3] corstone1000: enable isp1763 usb controller and mmc

[Rui Miguel Silva]

MPS3 board have a ISP1763 usb controller, enable it to be used
for mass storage access for example. Enable the usb command
also and for the FVP support for mass storage enable the mmc
command.

Signed-off-by: Rui Miguel Silva 
---
 configs/corstone1000_defconfig | 3 +++
 include/configs/corstone1000.h | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig
index 49a651aba238..dcf0a59a088c 100644
--- a/configs/corstone1000_defconfig
+++ b/configs/corstone1000_defconfig
@@ -27,6 +27,8 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 CONFIG_CMD_LOADM=y
 # CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
@@ -49,4 +51,5 @@ CONFIG_DM_RTC=y
 CONFIG_RTC_EMULATION=y
 CONFIG_DM_SERIAL=y
 CONFIG_USB=y
+CONFIG_USB_ISP1760=y
 CONFIG_ERRNO_STR=y
diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h
index 38d7fe8d0d42..8e0230c135e3 100644
--- a/include/configs/corstone1000.h
+++ b/include/configs/corstone1000.h
@@ -24,4 +24,10 @@
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 
+#define BOOT_TARGET_DEVICES(func) \
+   func(USB, usb, 0)
+
+#include 
+
+
 #endif
-- 
2.36.1

[PATCH v4 1/3] usb: common: move urb code to common

[Rui Miguel Silva]

Move urb code from musb only use to a more common scope, so other
drivers in the future can use the handling of urb in usb.

Signed-off-by: Rui Miguel Silva 
---
 drivers/usb/common/Makefile   |   2 +
 drivers/usb/common/usb_urb.c  | 160 ++
 drivers/usb/host/r8a66597-hcd.c   |  30 +---
 drivers/usb/musb-new/musb_core.c  |   2 +-
 drivers/usb/musb-new/musb_host.c  |   2 +-
 drivers/usb/musb-new/musb_host.h  |   2 +-
 drivers/usb/musb-new/musb_uboot.c |  38 +
 drivers/usb/musb-new/musb_uboot.h |   2 +-
 .../linux/usb/usb_urb_compat.h|  47 -
 include/usb_defs.h|  32 
 10 files changed, 241 insertions(+), 76 deletions(-)
 create mode 100644 drivers/usb/common/usb_urb.c
 rename drivers/usb/musb-new/usb-compat.h => include/linux/usb/usb_urb_compat.h 
(59%)

diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 3bedbf213f47..dc05cb0a5077 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,5 +4,7 @@
 #
 
 obj-$(CONFIG_$(SPL_)DM_USB) += common.o
+obj-$(CONFIG_USB_MUSB_HCD) += usb_urb.o
+obj-$(CONFIG_USB_MUSB_UDC) += usb_urb.o
 obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
 obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
diff --git a/drivers/usb/common/usb_urb.c b/drivers/usb/common/usb_urb.c
new file mode 100644
index ..be3b6b9f32e8
--- /dev/null
+++ b/drivers/usb/common/usb_urb.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common code for usb urb handling, based on the musb-new code
+ *
+ * Copyright 2021 Linaro, Rui Miguel Silva 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#if CONFIG_IS_ENABLED(DM_USB)
+struct usb_device *usb_dev_get_parent(struct usb_device *udev)
+{
+   struct udevice *parent = udev->dev->parent;
+
+   /*
+* When called from usb-uclass.c: usb_scan_device() udev->dev points
+* to the parent udevice, not the actual udevice belonging to the
+* udev as the device is not instantiated yet.
+*
+* If dev is an usb-bus, then we are called from usb_scan_device() for
+* an usb-device plugged directly into the root port, return NULL.
+*/
+   if (device_get_uclass_id(udev->dev) == UCLASS_USB)
+   return NULL;
+
+   /*
+* If these 2 are not the same we are being called from
+* usb_scan_device() and udev itself is the parent.
+*/
+   if (dev_get_parent_priv(udev->dev) != udev)
+   return udev;
+
+   /* We are being called normally, use the parent pointer */
+   if (device_get_uclass_id(parent) == UCLASS_USB_HUB)
+   return dev_get_parent_priv(parent);
+
+   return NULL;
+}
+#else
+struct usb_device *usb_dev_get_parent(struct usb_device *udev)
+{
+   return udev->parent;
+}
+#endif
+
+static void usb_urb_complete(struct urb *urb)
+{
+   urb->dev->status &= ~USB_ST_NOT_PROC;
+   urb->dev->act_len = urb->actual_length;
+
+   if (urb->status == -EINPROGRESS)
+   urb->status = 0;
+}
+
+void usb_urb_fill(struct urb *urb, struct usb_host_endpoint *hep,
+ struct usb_device *dev, int endpoint_type,
+ unsigned long pipe, void *buffer, int len,
+ struct devrequest *setup, int interval)
+{
+   int epnum = usb_pipeendpoint(pipe);
+   int is_in = usb_pipein(pipe);
+   u16 maxpacketsize = is_in ? dev->epmaxpacketin[epnum] :
+   dev->epmaxpacketout[epnum];
+
+   memset(urb, 0, sizeof(struct urb));
+   memset(hep, 0, sizeof(struct usb_host_endpoint));
+   INIT_LIST_HEAD(>urb_list);
+   INIT_LIST_HEAD(>urb_list);
+   urb->ep = hep;
+   urb->complete = usb_urb_complete;
+   urb->status = -EINPROGRESS;
+   urb->dev = dev;
+   urb->pipe = pipe;
+   urb->transfer_buffer = buffer;
+   urb->transfer_dma = (unsigned long)buffer;
+   urb->transfer_buffer_length = len;
+   urb->setup_packet = (unsigned char *)setup;
+
+   urb->ep->desc.wMaxPacketSize = __cpu_to_le16(maxpacketsize);
+   urb->ep->desc.bmAttributes = endpoint_type;
+   urb->ep->desc.bEndpointAddress = ((is_in ? USB_DIR_IN : USB_DIR_OUT) |
+ epnum);
+   urb->ep->desc.bInterval = interval;
+}
+
+int usb_urb_submit(struct usb_hcd *hcd, struct urb *urb)
+{
+   const struct usb_urb_ops *ops = hcd->urb_ops;
+   unsigned long timeout;
+   int ret;
+
+   if (!ops)
+   return -EINVAL;
+
+   ret = ops->urb_enqueue(hcd, urb, 0);
+   if (ret < 0) {
+   printf("Failed to enqueue URB to controller\n");
+   return ret;
+   }
+
+   timeout = get_timer(0) + USB_TIMEOUT_MS(urb->pipe);
+   do {
+   if (ctrlc())
+ 

[PATCH v4 0/3] usb: add isp1760 hcd support

[Rui Miguel Silva]

Add support for the usb isp1760 host controller family, which
for example is present in MPS3 FPGA board from Arm (isp1763).

First we move some helper functions and defines to a more
common place to be shared by several urb users. (patch 1/3)

Then add the driver itself, is a ported version of the kernel
actual driver, which I am also the maintainer. (patch 2/3)

And last, enable it for the corstone1000 platform that uses
that MPS3 board for its implementation (patch 3/3).

Cheers,
   Rui

v3 -> v4:
- rebase on top of next and resend with Marek in --to

v2[3] -> v3:
- when you think you have amend commit and fix stay
  uncommitted.
  s/[HC_FIELD_MAX] = {};/[HC_FIELD_MAX] = {},/
v1[0] -> v2:
- gentle ping
- merge fix from kernel upstream [1]

PS: This should go on top of the corstone1000 platform enable
series [2]

0: https://lore.kernel.org/u-boot/20220512142016.2025129-1-rui.si...@linaro.org/
1: 
https://lore.kernel.org/linux-usb/20220516091424.391209-1-linus.wall...@linaro.org/
2: 
https://lore.kernel.org/u-boot/20220511095541.1461937-1-rui.si...@linaro.org/T/#t
3: https://lore.kernel.org/u-boot/20220523090119.1212016-1-rui.si...@linaro.org/

Rui Miguel Silva (3):
  usb: common: move urb code to common
  usb: add isp1760 family driver
  corstone1000: enable isp1763 usb controller and mmc

 Makefile  |1 +
 configs/corstone1000_defconfig|3 +
 drivers/usb/Kconfig   |2 +
 drivers/usb/common/Makefile   |3 +
 drivers/usb/common/usb_urb.c  |  160 ++
 drivers/usb/host/r8a66597-hcd.c   |   30 +-
 drivers/usb/isp1760/Kconfig   |   12 +
 drivers/usb/isp1760/Makefile  |6 +
 drivers/usb/isp1760/isp1760-core.c|  380 +++
 drivers/usb/isp1760/isp1760-core.h|   96 +
 drivers/usb/isp1760/isp1760-hcd.c | 2477 +
 drivers/usb/isp1760/isp1760-hcd.h |   81 +
 drivers/usb/isp1760/isp1760-if.c  |  125 +
 drivers/usb/isp1760/isp1760-regs.h|  292 ++
 drivers/usb/isp1760/isp1760-uboot.c   |   75 +
 drivers/usb/isp1760/isp1760-uboot.h   |   27 +
 drivers/usb/musb-new/musb_core.c  |2 +-
 drivers/usb/musb-new/musb_host.c  |2 +-
 drivers/usb/musb-new/musb_host.h  |2 +-
 drivers/usb/musb-new/musb_uboot.c |   38 +-
 drivers/usb/musb-new/musb_uboot.h |2 +-
 include/configs/corstone1000.h|6 +
 .../linux/usb/usb_urb_compat.h|   47 +-
 include/usb_defs.h|   32 +
 24 files changed, 3825 insertions(+), 76 deletions(-)
 create mode 100644 drivers/usb/common/usb_urb.c
 create mode 100644 drivers/usb/isp1760/Kconfig
 create mode 100644 drivers/usb/isp1760/Makefile
 create mode 100644 drivers/usb/isp1760/isp1760-core.c
 create mode 100644 drivers/usb/isp1760/isp1760-core.h
 create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
 create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
 create mode 100644 drivers/usb/isp1760/isp1760-if.c
 create mode 100644 drivers/usb/isp1760/isp1760-regs.h
 create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
 create mode 100644 drivers/usb/isp1760/isp1760-uboot.h
 rename drivers/usb/musb-new/usb-compat.h => include/linux/usb/usb_urb_compat.h 
(59%)

-- 
2.36.1

Re: [PATCH v3 0/3] usb: add isp1760 hcd support

[Rui Miguel Silva]

Hi Marek,
On Tue, Jun 28, 2022 at 05:44:47PM +0200, Marek Vasut wrote:
> On 6/28/22 16:59, Rui Miguel Silva wrote:
> > Hi,
> > On Mon, Jun 20, 2022 at 01:44:02PM -0400, Tom Rini wrote:
> > > On Mon, Jun 20, 2022 at 05:00:56PM +0100, Rui Miguel Silva wrote:
> > > > Hi Tom, On Tue Jun 14, 2022 at 6:45 PM WEST, Rui Miguel Silva
> > > > wrote:
> > > > > Hi *, On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva
> > > > > wrote:
> > > > > > Add support for the usb isp1760 host controller family, which
> > > > > > for example is present in MPS3 FPGA board from Arm (isp1763).
> > > > > > 
> > > > > > First we move some helper functions and defines to a more
> > > > > > common place to be shared by several urb users. (patch 1/3)
> > > > > > 
> > > > > > Then add the driver itself, is a ported version of the kernel
> > > > > > actual driver, which I am also the maintainer. (patch 2/3)
> > > > > > 
> > > > > > And last, enable it for the corstone1000 platform that uses
> > > > > > that MPS3 board for its implementation (patch 3/3).
> > > > > > 
> > > > > 
> > > > > Any chance this series get some feedback?
> > > > 
> > > > Am I missing something here? to get some comments on this series?
> > > 
> > > Marex?  Thanks.
> > 
> > Oh well, the weekly ping. Any comments on this series?
> 
> Can you rebase/resend and please CC me on the entire series ?

Sure, will do it.

Cheers,
   Rui
> 
> Thanks

[PATCH v2] powerpc: mpc85xx: Simplify jump to _start_cont in flash code

[Pali Rohár]

After more patches code for jumping to _start_cont symbol in flash memory
involved to code with useless mathematical operations. Currently it does:

  r3 := CONFIG_SYS_MONITOR_BASE + ABS(_start_cont) - CONFIG_SYS_MONITOR_BASE
  jump to r3

Which is equivalent of just:

  r3 := ABS(_start_cont)
  jump to r3

The purpose of that code is just to jump to _start_code symbol,
independently of program counter. So branch must be done to absolute
address. Trying to write:

  ba _start_cont

just cause linker error:

LD  u-boot
  powerpc-linux-gnuspe-ld.bfd: arch/powerpc/cpu/mpc85xx/start.o: in function 
`switch_as':
  (.bootpg+0x4b8): relocation truncated to fit: R_PPC_ADDR24 against symbol 
`_start_cont' defined in .text section in arch/powerpc/cpu/mpc85xx/start.o
  make: *** [Makefile:1801: u-boot] Error 1

Probably by the fact that absolute address cannot be expressed by 24-bits.
So write the code via mtlr+blr pattern as it was before and load general
purpose register with absolute address of the symbol:

  lis r3,_start_cont@h
  ori r3,r3,_start_cont@l
  mtlrr3
  blr

Seems that gcc and gnu ld linker support symbol@h and symbol@l syntax like
number@h and number@l without any problem. And disassembling of compiler
u-boot binary proved that lis+ori instructions are called with numbers
which represent halves of absolute address of _start_cont symbol.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Rebased on top of next branch, commit d61c11b8c894fad517677dc51ee82d1eade39c01
---
 arch/powerpc/cpu/mpc85xx/start.S | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 5009cbef54a0..8a6340d800c3 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1126,9 +1126,8 @@ switch_as:
 #else
/* Calculate absolute address in FLASH and jump there   */
/*--*/
-   lis r3,CONFIG_VAL(SYS_MONITOR_BASE)@h
-   ori r3,r3,CONFIG_VAL(SYS_MONITOR_BASE)@l
-   addir3,r3,_start_cont - CONFIG_VAL(SYS_MONITOR_BASE)
+   lis r3,_start_cont@h
+   ori r3,r3,_start_cont@l
mtlrr3
blr
 #endif
-- 
2.20.1

Re: [PATCH v3 0/3] usb: add isp1760 hcd support

[Marek Vasut]

On 6/28/22 16:59, Rui Miguel Silva wrote:

Hi,
On Mon, Jun 20, 2022 at 01:44:02PM -0400, Tom Rini wrote:

On Mon, Jun 20, 2022 at 05:00:56PM +0100, Rui Miguel Silva wrote:

Hi Tom, On Tue Jun 14, 2022 at 6:45 PM WEST, Rui Miguel Silva
wrote:

Hi *, On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva
wrote:

Add support for the usb isp1760 host controller family, which
for example is present in MPS3 FPGA board from Arm (isp1763).

First we move some helper functions and defines to a more
common place to be shared by several urb users. (patch 1/3)

Then add the driver itself, is a ported version of the kernel
actual driver, which I am also the maintainer. (patch 2/3)

And last, enable it for the corstone1000 platform that uses
that MPS3 board for its implementation (patch 3/3).



Any chance this series get some feedback?


Am I missing something here? to get some comments on this series?


Marex?  Thanks.


Oh well, the weekly ping. Any comments on this series?


Can you rebase/resend and please CC me on the entire series ?

Thanks

Re: [PATCH V7 2/4] ddr: imx8m: helper: load ddr firmware according to binman symbols

[Tom Rini]

On Tue, Jun 28, 2022 at 05:08:26PM +0300, Alper Nebi Yasak wrote:
> Hi Tom, Simon, Peng,
> 
> On 27/06/2022 06:41, Peng Fan (OSS) wrote:
> > From: Peng Fan 
> > 
> > By reading binman symbols, we no need hard coded IMEM_LEN/DMEM_LEN after
> > we update the binman dtsi to drop 0x8000/0x4000 length for the firmware.
> > 
> > And that could save binary size for many KBs.
> > 
> > Tested-by: Tim Harvey  #imx8m[m,n,p]-venice
> > Signed-off-by: Peng Fan 
> > Reviewed-by: Alper Nebi Yasak 
> > [Alper: Check BINMAN_SYMS_OK instead]
> > Signed-off-by: Alper Nebi Yasak 
> > ---
> >  drivers/ddr/imx/phy/helper.c | 47 +++-
> >  1 file changed, 41 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/ddr/imx/phy/helper.c b/drivers/ddr/imx/phy/helper.c
> > index 60d650e3089..e9e0294f87d 100644
> > --- a/drivers/ddr/imx/phy/helper.c
> > +++ b/drivers/ddr/imx/phy/helper.c
> > @@ -4,6 +4,7 @@
> >   */
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -24,15 +25,30 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #define DMEM_OFFSET_ADDR 0x00054000
> >  #define DDR_TRAIN_CODE_BASE_ADDR IP2APB_DDRPHY_IPS_BASE_ADDR(0)
> >  
> > +binman_sym_declare(ulong, ddr_1d_imem_fw, image_pos);
> > +binman_sym_declare(ulong, ddr_1d_imem_fw, size);
> > +
> > +binman_sym_declare(ulong, ddr_1d_dmem_fw, image_pos);
> > +binman_sym_declare(ulong, ddr_1d_dmem_fw, size);
> > +
> > +#if !IS_ENABLED(CONFIG_IMX8M_DDR3L)
> > +binman_sym_declare(ulong, ddr_2d_imem_fw, image_pos);
> > +binman_sym_declare(ulong, ddr_2d_imem_fw, size);
> > +
> > +binman_sym_declare(ulong, ddr_2d_dmem_fw, image_pos);
> > +binman_sym_declare(ulong, ddr_2d_dmem_fw, size);
> > +#endif
> > +
> > [...]
> 
> A terrible question popped into my head while thinking about binman
> symbols, and I feel obliged to ask. Would this be considered 'linking'
> these proprietary blobs to a GPL-licensed U-Boot SPL binary?

No, I don't think so.  This isn't any different than the other types of
technical implementations done to allow for GPL things to start / find /
load / get information back from non-GPL things.

-- 
Tom


signature.asc
Description: PGP signature

Pull request: u-boot-imx u-boot-imx-20220628

[Stefano Babic]

Hi Tom,

last i.MX's fixes for the release.


The following changes since commit bfa9306e140c136e43d0efc9574991db46ad8c9e:

  Merge branch 'master' of 
https://source.denx.de/u-boot/custodians/u-boot-sunxi (2022-06-26 
21:06:08 -0400)


are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
tags/u-boot-imx-20220628


for you to fetch changes up to b5023254b88a67fcbca913e212e3401dea521fc9:

  kontron-sl-mx8mm: Add CAAM support (2022-06-28 15:24:31 +0200)


Fixes for 2022.07

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/12541


Andrejs Cainikovs (1):
  imx8m: fixup thermal trips

Fabio Estevam (1):
  kontron-sl-mx8mm: Add CAAM support

Francesco Dolcini (3):
  toradex: apalis/colibri_imx6: Fix CLKO1/CLKO2 output
  mx6: ddr: Fix disabling on-die termination
  board: apalis_imx6: DDR init using mx6_dram_cfg()

Frieder Schrempf (2):
  pmic: pca9450: Add optional SD_VSEL GPIO for LDO5
  imx: kontron-sl-mx8mm: Enable PCA9450 regulator driver and fix SD 
card access


Marek Vasut (1):
  ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver

 arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi   |  17 +
 arch/arm/mach-imx/imx8m/Kconfig |   3 +
 arch/arm/mach-imx/imx8m/soc.c   |  49 
++

 arch/arm/mach-imx/mx6/ddr.c |  13 +++-
 board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c |   9 +++
 board/kontron/sl-mx8mm/spl.c|   9 +++
 board/toradex/apalis_imx6/apalis_imx6.c | 456 
+---

 board/toradex/colibri_imx6/colibri_imx6.c   |  14 ++--
 configs/imx8mm_data_modul_edm_sbc_defconfig |   1 +
 configs/kontron-sl-mx8mm_defconfig  |   2 +
 drivers/power/pmic/pca9450.c|  27 
 include/configs/imx8mm_data_modul_edm_sbc.h |  20 --
 12 files changed, 333 insertions(+), 287 deletions(-)


Best regards,
Stefano

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

Re: [PATCH v3 0/3] usb: add isp1760 hcd support

[Rui Miguel Silva]

Hi,
On Mon, Jun 20, 2022 at 01:44:02PM -0400, Tom Rini wrote:
> On Mon, Jun 20, 2022 at 05:00:56PM +0100, Rui Miguel Silva wrote:
> > Hi Tom, On Tue Jun 14, 2022 at 6:45 PM WEST, Rui Miguel Silva
> > wrote:
> > > Hi *, On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva
> > > wrote:
> > > > Add support for the usb isp1760 host controller family, which
> > > > for example is present in MPS3 FPGA board from Arm (isp1763).
> > > > 
> > > > First we move some helper functions and defines to a more
> > > > common place to be shared by several urb users. (patch 1/3)
> > > > 
> > > > Then add the driver itself, is a ported version of the kernel
> > > > actual driver, which I am also the maintainer. (patch 2/3)
> > > > 
> > > > And last, enable it for the corstone1000 platform that uses
> > > > that MPS3 board for its implementation (patch 3/3).
> > > >
> > >
> > > Any chance this series get some feedback?
> > 
> > Am I missing something here? to get some comments on this series?
> 
> Marex?  Thanks.

Oh well, the weekly ping. Any comments on this series?

Cheers, Rui

> 
> -- Tom

Re: [PATCH] aspeed/ast2600: Fix SPL linker script

[Tom Rini]

On Tue, Jun 28, 2022 at 01:57:25PM +0930, Joel Stanley wrote:

> The commit 99e2fbcb69f0 ("linker_lists: Rename sections to remove .
> prefix") changed the name of the linker list sections. As the Aspeed SPL
> linker wasn't in the tree yet, it missed the change.
> 
> This updates the SPL linker to match arch/arm/cpu/u-boot-spl.lds which
> Aspeed was copied from.
> 
> Fixes: 442a69c14375 ("configs: ast2600: Move SPL bss section to DRAM space")
> Signed-off-by: Joel Stanley 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3] powerpc: mpc85xx: Set TEXT_BASE addresses to real base values

[Tom Rini]

On Thu, Jun 16, 2022 at 02:19:44PM +0200, Pali Rohár wrote:

> Currently CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE addresses are
> manually increased by 0x1000 due to .bootpg section. This section has size
> of 0x1000 bytes and is manually put by linker script before .text section
> (and therefore before base address) when CONFIG_SYS_MPC85XX_NO_RESETVEC is
> set. Due to this fact lot of other config options are manually increased by
> 0x1000 value to make correct layout. Note that entry point is not on
> CONFIG_SPL_TEXT_BASE (image+0x1000) but it is really on address
> CONFIG_SPL_TEXT_BASE-0x1000 (means at the start of the image).
> 
> Cleanup handling of .bootpg section when CONFIG_SYS_MPC85XX_NO_RESETVEC is
> set. Put .bootpg code directly into .text section and move text base
> address to the start of .bootpg code. And finally remove +0x1000 value from
> lot of config options. With this removal custom PHDRS is not used anymore,
> so remove it too.
> 
> After this change entry point would be at CONFIG_SPL_TEXT_BASE and not at
> address -0x1000 anymore.
> 
> Tested on P2020 board with SPL and proper U-Boot.
> 
> Signed-off-by: Pali Rohár 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH RESEND 4/5] ast2600: Configure u-boot-with-spl.bin target

[Tom Rini]

On Mon, Jun 27, 2022 at 05:28:10PM +0930, Joel Stanley wrote:

> For the u-boot-with-spl.bin target to be useful for the AST2600, set the
> maximum SPL size which also sets the padding length.
> 
> The normal way of loading u-boot is as a FIT, so configure u-boot.img as
> the SPL playload.
> 
> With this the following simple steps can be used to build and boot a
> system:
> 
>   make u-boot-with-spl.bin
>   truncate -s 64M u-boot-with-spl.bin
>   qemu-system-arm -nographic -M ast2600-evb \
> -drive file=u-boot-with-spl.bin,if=mtd,format=raw
> 
> Signed-off-by: Joel Stanley 
> Reviewed-by: Chia-Wei Wang 
> Reviewed-by: Cédric Le Goater 

This doesn't quite apply correct now as CONFIG_SPL_MAX_SIZE is in
Kconfig.  I migrated that manually but now CI doesn't run:
https://source.denx.de/u-boot/u-boot/-/jobs/457298
so I wonder if I migrated it wrong, or something else.  To be clear, I
have applied
https://patchwork.ozlabs.org/project/uboot/patch/20220628042725.217333-1-j...@jms.id.au/
first.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 6/9] dm: core: Support accessing core tags

[AKASHI Takahiro]

On Tue, Jun 28, 2022 at 09:37:56AM -0400, Simon Glass wrote:
> Hi Simon,
> 
> On Sun, May 08, 2022 at 04:39:24AM -0600, Simon Glass wrote:
> > At present tag numbers are only allocated for non-core data, meaning that
> > the 'core' data, like priv and plat, are accessed through dedicated
> > functions.
> >
> > For debugging and consistency it is convenient to use tags for this 'core'
> > data too. Add support for this, with new tag numbers and functions to
> > access the pointer and size for each.
> >
> > Update one of the test drivers so that the uclass-private data can be
> > tested here.
> >
> > There is some code duplication with functions like device_alloc_priv() but
> > this is not addressed for now. At some point, some rationalisation may
> > help to reduce code size, but more thought it needed on that.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/device.c   | 65 +
> >  drivers/misc/test_drv.c |  4 ++-
> >  include/dm/device.h | 25 +
> >  include/dm/tag.h| 13 ++-
> >  test/dm/core.c  | 80 +
> >  tools/dtoc/test_dtoc.py |  4 +++
> >  6 files changed, 189 insertions(+), 2 deletions(-)
> >
> Applied to u-boot-dm, thanks!

I expect you to reply to my comments:
https://lists.denx.de/pipermail/u-boot/2022-May/483606.html

-Takahiro Akashi

Re: [PATCH 0/8] u-boot: fs: add generic unaligned read handling

[Tom Rini]

On Tue, Jun 28, 2022 at 03:28:00PM +0800, Qu Wenruo wrote:
> [BACKGROUND]
> Unlike FUSE/Kernel which always pass aligned read range, U-boot fs code
> just pass the request range to underlying fses.
> 
> Under most case, this works fine, as U-boot only really needs to read
> the whole file (aka, 0 for both offset and len, len will be later
> determined using file size).
> 
> But if some advanced user/script wants to extract kernel/initramfs from
> combined image, we may need to do unaligned read in that case.
> 
> [ADVANTAGE]
> This patchset will handle unaligned read range in _fs_read():
> 
> - Get blocksize of the underlying fs
> 
> - Read the leading block contianing the unaligned range
>   The full block will be stored in a local buffer, then only copy
>   the bytes in the unaligned range into the destination buffer.
> 
>   If the first block covers the whole range, we just call it aday.
> 
> - Read the aligned range if there is any
> 
> - Read the tailing block containing the unaligned range
>   And copy the covered range into the destination.
> 
> [DISADVANTAGE]
> There are mainly two problems:
> 
> - Extra memory allocation for every _fs_read() call
>   For the leading and tailing block.
> 
> - Extra path resolving
>   All those supported fs will have to do extra path resolving up to 2
>   times (one for the leading block, one for the tailing block).
>   This may slow down the read.

This conceptually seems like a good thing.  Can you please post some
before/after times of reading large images from the supported
filesystems?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V7 2/4] ddr: imx8m: helper: load ddr firmware according to binman symbols

[Alper Nebi Yasak]

Hi Tom, Simon, Peng,

On 27/06/2022 06:41, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> By reading binman symbols, we no need hard coded IMEM_LEN/DMEM_LEN after
> we update the binman dtsi to drop 0x8000/0x4000 length for the firmware.
> 
> And that could save binary size for many KBs.
> 
> Tested-by: Tim Harvey  #imx8m[m,n,p]-venice
> Signed-off-by: Peng Fan 
> Reviewed-by: Alper Nebi Yasak 
> [Alper: Check BINMAN_SYMS_OK instead]
> Signed-off-by: Alper Nebi Yasak 
> ---
>  drivers/ddr/imx/phy/helper.c | 47 +++-
>  1 file changed, 41 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ddr/imx/phy/helper.c b/drivers/ddr/imx/phy/helper.c
> index 60d650e3089..e9e0294f87d 100644
> --- a/drivers/ddr/imx/phy/helper.c
> +++ b/drivers/ddr/imx/phy/helper.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -24,15 +25,30 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DMEM_OFFSET_ADDR 0x00054000
>  #define DDR_TRAIN_CODE_BASE_ADDR IP2APB_DDRPHY_IPS_BASE_ADDR(0)
>  
> +binman_sym_declare(ulong, ddr_1d_imem_fw, image_pos);
> +binman_sym_declare(ulong, ddr_1d_imem_fw, size);
> +
> +binman_sym_declare(ulong, ddr_1d_dmem_fw, image_pos);
> +binman_sym_declare(ulong, ddr_1d_dmem_fw, size);
> +
> +#if !IS_ENABLED(CONFIG_IMX8M_DDR3L)
> +binman_sym_declare(ulong, ddr_2d_imem_fw, image_pos);
> +binman_sym_declare(ulong, ddr_2d_imem_fw, size);
> +
> +binman_sym_declare(ulong, ddr_2d_dmem_fw, image_pos);
> +binman_sym_declare(ulong, ddr_2d_dmem_fw, size);
> +#endif
> +
> [...]

A terrible question popped into my head while thinking about binman
symbols, and I feel obliged to ask. Would this be considered 'linking'
these proprietary blobs to a GPL-licensed U-Boot SPL binary?

[PATCH 2/2] pmic: pca9450: clear PRESET_EN bit for BUCK1/2/3 voltage settings

[Heiko Thiery]

The regulator driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to
set the voltage for the buck regulators 1, 2 and 3. This has no effect as the
PRESET_EN bit is set by default and therefore the preset values are used
instead, which are set to 850 mV.

This is a port of the same change in the Linux kernel:
98b94b6e38ca0 ("regulator: pca9450: Clear PRESET_EN bit to fix BUCK1/2/3 
voltage setting")

Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 
---
 drivers/power/pmic/pca9450.c | 6 ++
 include/power/pca9450.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index fecab0496f..1c59362ab4 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -94,6 +94,12 @@ static int pca9450_probe(struct udevice *dev)
 
priv->regmap = syscon_node_to_regmap(dev_ofnode(dev));
 
+   /* Clear PRESET_EN bit in BUCK123_DVS to use DVS registers */
+   if (CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
+   ret = regmap_update_bits(priv->regmap, PCA9450_BUCK123_DVS,
+BUCK123_PRESET_EN, 0);
+   }
+
if (dev_read_bool(dev, "nxp,wdog_b-warm-reset"))
reset_ctrl = WDOG_B_CFG_WARM;
else
diff --git a/include/power/pca9450.h b/include/power/pca9450.h
index bf9be7d6bb..60e37c671a 100644
--- a/include/power/pca9450.h
+++ b/include/power/pca9450.h
@@ -67,6 +67,9 @@ enum {
 #define PCA9450_LDO34_MASK 0x1f
 #define PCA9450_LDO5_MASK  0x0f
 
+/* PCA9450_REG_BUCK123_PRESET_EN bit */
+#define BUCK123_PRESET_EN  0x80
+
 /* PCA9450_REG_RESET_CTRL bits */
 #define WDOG_B_CFG_MASK0xC0
 #define WDOG_B_CFG_NONE0x00
-- 
2.30.2

[PATCH 1/2] pmic: pca9450: enable system reset on WDOG_B assertion

[Heiko Thiery]

By default the PCA9450 doesn't handle the assertion of the WDOG_B
signal, but this is required to guarantee that things like software
resets triggered by the watchdog work reliably.

This is a port of the same changes in the Linux kernel:
f7684f5a048f ("regulator: pca9450: Enable system reset on WDOG_B assertion")
2364a64d0673 ("regulator: pca9450: Make warm reset on WDOG_B assertion")

Cc: Frieder Schrempf 
Signed-off-by: Heiko Thiery 
---
 drivers/power/pmic/Kconfig   |  4 
 drivers/power/pmic/pca9450.c | 15 +++
 include/power/pca9450.h  |  7 +++
 3 files changed, 26 insertions(+)

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index bb3960020d..d30d6d25c4 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -158,6 +158,8 @@ config SPL_DM_PMIC_MP5416
 
 config DM_PMIC_PCA9450
bool "Enable Driver Model for PMIC PCA9450"
+   select REGMAP
+   select SYSCON
help
  This config enables implementation of driver-model pmic uclass 
features
  for PMIC PCA9450. The driver implements read/write operations.
@@ -165,6 +167,8 @@ config DM_PMIC_PCA9450
 config SPL_DM_PMIC_PCA9450
bool "Enable Driver Model for PMIC PCA9450"
depends on SPL_DM_PMIC
+   select SPL_REGMAP
+   select SPL_SYSCON
help
  This config enables implementation of driver-model pmic uclass 
features
  for PMIC PCA9450 in SPL. The driver implements read/write operations.
diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index a186edc08d..fecab0496f 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +32,7 @@ static const struct pmic_child_info pmic_children_info[] = {
 };
 
 struct pca9450_priv {
+   struct regmap *regmap;
struct gpio_desc *sd_vsel_gpio;
 };
 
@@ -86,8 +89,20 @@ static int pca9450_bind(struct udevice *dev)
 static int pca9450_probe(struct udevice *dev)
 {
struct pca9450_priv *priv = dev_get_priv(dev);
+   unsigned int reset_ctrl;
int ret = 0;
 
+   priv->regmap = syscon_node_to_regmap(dev_ofnode(dev));
+
+   if (dev_read_bool(dev, "nxp,wdog_b-warm-reset"))
+   reset_ctrl = WDOG_B_CFG_WARM;
+   else
+   reset_ctrl = WDOG_B_CFG_COLD_LDO12;
+
+   /* Set reset behavior on assertion of WDOG_B signal */
+   ret = regmap_update_bits(priv->regmap, PCA9450_RESET_CTRL,
+WDOG_B_CFG_MASK, reset_ctrl);
+
if (CONFIG_IS_ENABLED(DM_GPIO) && 
CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
priv->sd_vsel_gpio = devm_gpiod_get_optional(dev, "sd-vsel",
 GPIOD_IS_OUT |
diff --git a/include/power/pca9450.h b/include/power/pca9450.h
index fa0405fcb8..bf9be7d6bb 100644
--- a/include/power/pca9450.h
+++ b/include/power/pca9450.h
@@ -67,4 +67,11 @@ enum {
 #define PCA9450_LDO34_MASK 0x1f
 #define PCA9450_LDO5_MASK  0x0f
 
+/* PCA9450_REG_RESET_CTRL bits */
+#define WDOG_B_CFG_MASK0xC0
+#define WDOG_B_CFG_NONE0x00
+#define WDOG_B_CFG_WARM0x40
+#define WDOG_B_CFG_COLD_LDO12  0x80
+#define WDOG_B_CFG_COLD0xC0
+
 #endif
-- 
2.30.2

[PATCH 0/2] pmic: pca9450: Initialization of pmic like done in linux

[Heiko Thiery]

To be able to initialize the PMIC voltages by using the PCA9450 regulator
driver we need to properly disable the BUCK1/2/3 preset behavior.

Also the RESET_CTRL/WDOG_B_CFG behavior can be done by the PC9450 PMIC driver.

With that enabled the PMIC custom configurations done in SPL code for
boards that has the PCA9450 implemented can be cleaned.

Heiko Thiery (2):
  pmic: pca9450: enable system reset on WDOG_B assertion
  pmic: pca9450: clear PRESET_EN bit for BUCK1/2/3 voltage settings

 drivers/power/pmic/Kconfig   |  4 
 drivers/power/pmic/pca9450.c | 21 +
 include/power/pca9450.h  | 10 ++
 3 files changed, 35 insertions(+)

-- 
2.30.2

Re: [PATCH 1/1] efi_loader: initialize console size late

[Fabio Estevam]

On Tue, Jun 28, 2022 at 11:01 AM Heinrich Schuchardt
 wrote:

> The patch is merged June 19th:
>
> e05bd68ed5fc ("test: work around for EFI terminal size probing")
>
> Why do you ask?

Because I haven't seen an "applied" message in this thread.

I see it in mainline now, thanks.

Re: [PATCH 1/1] efi_loader: initialize console size late

[Heinrich Schuchardt]

On 6/28/22 15:52, Fabio Estevam wrote:

Hi Heinrich,

On Fri, Jun 17, 2022 at 1:59 AM Heinrich Schuchardt
 wrote:


This causes: https://source.denx.de/u-boot/u-boot/-/jobs/450891#L229
for all instances of sandbox running that test.



This is a only a bug to the test environment:

test/py/u_boot_console_base.py:110:
self.prompt_compiled = re.compile('^' + re.escape(self.prompt),
re.MULTILINE)

There must not be any byte before the prompt on the line for the test
environment to recognize it as a prompt.

I will look into the problem.


Have you had a chance to look into this?

2022.07 is really close and it would be nice to get a fix for this regression.

Thanks


The patch is merged June 19th:

e05bd68ed5fc ("test: work around for EFI terminal size probing")

Why do you ask?

Best regards

Heinrich

Re: [PATCH 1/1] efi_loader: initialize console size late

[Fabio Estevam]

On Tue, Jun 28, 2022 at 10:55 AM Tom Rini  wrote:

> I thought this was worked around for now?  The non-testing case should
> be fine again, and tests do need to do additional code to work, which is
> not ideal, but good enough for the moment.

I haven't realized that the patch has been applied.

We are good now, thanks!

Re: [PATCH 1/1] efi_loader: initialize console size late

[Tom Rini]

On Tue, Jun 28, 2022 at 10:52:32AM -0300, Fabio Estevam wrote:
> Hi Heinrich,
> 
> On Fri, Jun 17, 2022 at 1:59 AM Heinrich Schuchardt
>  wrote:
> 
> > > This causes: https://source.denx.de/u-boot/u-boot/-/jobs/450891#L229
> > > for all instances of sandbox running that test.
> > >
> >
> > This is a only a bug to the test environment:
> >
> > test/py/u_boot_console_base.py:110:
> > self.prompt_compiled = re.compile('^' + re.escape(self.prompt),
> > re.MULTILINE)
> >
> > There must not be any byte before the prompt on the line for the test
> > environment to recognize it as a prompt.
> >
> > I will look into the problem.
> 
> Have you had a chance to look into this?
> 
> 2022.07 is really close and it would be nice to get a fix for this regression.

I thought this was worked around for now?  The non-testing case should
be fine again, and tests do need to do additional code to work, which is
not ideal, but good enough for the moment.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] efi_loader: initialize console size late

[Fabio Estevam]

Hi Heinrich,

On Fri, Jun 17, 2022 at 1:59 AM Heinrich Schuchardt
 wrote:

> > This causes: https://source.denx.de/u-boot/u-boot/-/jobs/450891#L229
> > for all instances of sandbox running that test.
> >
>
> This is a only a bug to the test environment:
>
> test/py/u_boot_console_base.py:110:
> self.prompt_compiled = re.compile('^' + re.escape(self.prompt),
> re.MULTILINE)
>
> There must not be any byte before the prompt on the line for the test
> environment to recognize it as a prompt.
>
> I will look into the problem.

Have you had a chance to look into this?

2022.07 is really close and it would be nice to get a fix for this regression.

Thanks

Re: [PATCH 1/9] dm: core: Rename dm_dump_all()

[Simon Glass]

This is not a good name anymore as it does not dump everything. Rename it
to dm_dump_tree() to avoid confusion.

Signed-off-by: Simon Glass 
---

 cmd/dm.c| 8 
 drivers/core/dump.c | 2 +-
 include/dm/util.h   | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH v2] patman: Fix defaults not propagating to subparsers

[Simon Glass]

On python 3.8.10 (and 3.10), subparsers are not updated with defaults. I
suspect this is related to [1]. Fix this by explicitly updating
subparsers with settings.

[1] https://github.com/python/cpython/issues/89398

Fixes: 3145b63513 ("patman: Update defaults in subparsers")
Signed-off-by: Sean Anderson 
Reviewed-by: Alper Nebi Yasak 
Tested-by: Alper Nebi Yasak 
---

Changes in v2:
- Fix spelling of "propagating" in commit message
- Update comment to more clearly indicate intent

 tools/patman/settings.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 3/9] dm: core: Fix addresses in the dm static command

[Simon Glass]

This command converts pointers to addresses, but the pointers being
converted are in the image's rodata region. For sandbox this means it
is not in DRAM so it does not make sense to do this conversion.

Fix this by showing a simple pointer instead. Drop the unnecessary
@ and hex prefixes.

Signed-off-by: Simon Glass 
---

 drivers/core/dump.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 4/5] patman: test_util: Customize unittest test results for more info

[Simon Glass]

By default, unittest test summaries only print extended info about tests
that failed or couldn't run due to an error. Use a custom text result
class to print info about more cases: skipped tests, expected failures
and unexpected successes.

Signed-off-by: Alper Nebi Yasak 
---
This could be squashed into the previous patch, but makes the diff ugly.

 tools/patman/test_util.py | 46 +++
 1 file changed, 46 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH 2/9] dm: core: Sort dm subcommands

[Simon Glass]

Put these in alphabetic order, both in the help and in the implementation,
as there are quite a few subcommands now. Tweak the help for 'dm tree' to
better explain what it does.

Signed-off-by: Simon Glass 
---

 cmd/dm.c | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

Applied to u-boot-dm, thanks!

Please pull u-boot-dm/next

[Simon Glass]

Hi Tom,

This is for the -next branch.

https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/e87da5704ffa6fc782d93d137fa30a37a5df3566


The following changes since commit ea82ed8c2eaee0a0f7dee31016aaee4ce88e9ea7:

  Merge branch '2022-06-27-add-armv8-sha1-sha256-support' into next
(2022-06-27 13:39:19 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-28jun22

for you to fetch changes up to e87da5704ffa6fc782d93d137fa30a37a5df3566:

  armv8: u-boot-spl.lds: mark __image_copy_start as symbol (2022-06-28
03:09:52 +0100)


nman external-symbol improvements
Driver model memory-usage reporting
patman test-reporting improvements
Add bloblist design goals


Alper Nebi Yasak (12):
  patman: test_util: Fix printing results for failed tests
  patman: test_util: Handle nonexistent tests while loading tests
  patman: test_util: Use unittest text runner to print test results
  patman: test_util: Customize unittest test results for more info
  patman: test_util: Print test stdout/stderr within test summaries
  spl: binman: Fix use of undeclared u_boot_any symbols
  spl: binman: Make TPL_BINMAN_SYMBOLS depend on TPL_FRAMEWORK
  spl: binman: Declare extern symbols for VPL as well
  spl: binman: Split binman symbols support from enabling binman
  spl: binman: Add config options for binman symbols in VPL
  spl: binman: Check at runtime if binman symbols were filled in
  spl: binman: Disable u_boot_any symbols for i.MX8M boards

Heinrich Schuchardt (6):
  sandbox: add function os_printf()
  sandbox: show error if the device-tree cannot be loaded
  dm: fix formatting of uclass dump
  sandbox: raise SANDBOX_RAM_SIZE_MB default to 256
  test: fix some pylint errors in test_bind.py
  sandbox: cast to pointer from integer of different size

Peng Fan (1):
  armv8: u-boot-spl.lds: mark __image_copy_start as symbol

Sean Anderson (4):
  sandbox: usb: Fix out-of-bounds read when fd=-1
  dm: core: Provide fallbacks for ofnode_conf_read_...
  dm: core: Use device_foreach_child where possible
  patman: Fix defaults not propagating to subparsers

Simon Glass (11):
  bloblist: Describe the design goals
  dtoc: Update fdt tests to use test_util
  dm: core: Rename dm_dump_all()
  dm: core: Sort dm subcommands
  dm: core: Fix addresses in the dm static command
  dm: core: Add documentation for the dm command
  dm: core: Switch the testbus driver to use a new struct
  dm: core: Support accessing core tags
  dm: core: Add a way to collect memory usage
  dm: core: Add a command to show driver model statistics
  dm: spl: Allow SPL to show memory usage

 arch/arm/cpu/armv8/u-boot-spl.lds   |   2 +-
 arch/sandbox/Kconfig|   4 +-
 arch/sandbox/cpu/cpu.c  |   8 +-
 arch/sandbox/cpu/os.c   |  13 +
 cmd/dm.c|  72 ++--
 common/spl/Kconfig  |  23 +-
 common/spl/Kconfig.tpl  |  27 +-
 common/spl/Kconfig.vpl  |  25 ++
 common/spl/spl.c|  25 +-
 common/spl/spl_ram.c|   2 +-
 doc/develop/bloblist.rst|   2 +
 doc/usage/cmd/dm.rst| 487 
 doc/usage/index.rst |   1 +
 drivers/core/Kconfig|  21 ++
 drivers/core/device-remove.c|   4 +-
 drivers/core/device.c   |  86 -
 drivers/core/devres.c   |   2 +-
 drivers/core/dump.c |  83 -
 drivers/core/root.c |  53 +++
 drivers/core/tag.c  |  29 ++
 drivers/misc/qfw_sandbox.c  |   2 +-
 drivers/misc/test_drv.c |   6 +-
 drivers/usb/emul/sandbox_flash.c|   5 +-
 include/binman_sym.h|  51 ++-
 include/bloblist.h  |  62 +++-
 include/dm/device.h |  25 ++
 include/dm/ofnode.h |  66 ++--
 include/dm/root.h   |  45 +++
 include/dm/tag.h|  32 +-
 include/dm/test.h   |   7 +
 include/dm/util.h   |  11 +-
 include/os.h|   7 +
 include/spl.h   |   2 +
 test/dm/core.c  |  91 ++
 test/py/tests/test_bind.py  | 345 ++--
 tools/binman/elf.py |  12 +-
 tools/binman/elf_test.py|  12 +-
 tools/binman/ftest.py   |  33 +-
 

Re: [PATCH] dm: core: Use device_foreach_child where possible

[Simon Glass]

We have some nice macros for iterating over devices in device.h, but they
are not used by the driver core. Convert all the users I could find.

Signed-off-by: Sean Anderson 
---

 drivers/core/device-remove.c |  4 ++--
 drivers/core/device.c| 21 ++---
 drivers/core/devres.c|  2 +-
 drivers/core/dump.c  |  2 +-
 4 files changed, 14 insertions(+), 15 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH] dtoc: Update fdt tests to use test_util

[Simon Glass]

On 19/03/2022 03:01, Simon Glass wrote:
> Use the common functions to run tests and report results. Ensure that the
> result code indicates success or failure.
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/dtoc/test_fdt.py | 27 ++-
>  1 file changed, 10 insertions(+), 17 deletions(-)

Reviewed-by: Alper Nebi Yasak 

Applied to u-boot-dm, thanks!

Re: [PATCH] bloblist: Describe the design goals

[Simon Glass]

Add a comment explaining the design goals of bloblist, to make it easier
for people to understand and comment on the structure.

Signed-off-by: Simon Glass 
---

 doc/develop/bloblist.rst |  2 ++
 include/bloblist.h   | 62 ++--
 2 files changed, 62 insertions(+), 2 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH] dm: core: Provide fallbacks for ofnode_conf_read_...

[Simon Glass]

On 3/28/22 6:14 PM, Sean Anderson wrote:
> Because fdt_get_config_str et al. were moved/renamed to
> ofnode_conf_read_str, they now depend on CONFIG_DM as well as
> CONFIG_OF_CONTROL. Add some fallback implementations, preventing a
> linker error when CONFIG_SPL_OF_CONTROL and CONFIG_SPL_ENV_IS_IN_MMC are
> enabled and CONFIG_SPL_DM is disabled.
>
> Fixes: 7de8bd03c3 ("treewide: fdt: Move fdt_get_config_... to 
> ofnode_conf_read...")
> Signed-off-by: Sean Anderson 
> ---
>
>  include/dm/ofnode.h | 17 +
>  1 file changed, 17 insertions(+)
>
Applied to u-boot-dm, thanks!

Re: [PATCH 8/9] dm: core: Add a command to show driver model statistics

[Simon Glass]

This command shows the memory used by driver model along with various
hints as to what it might be if some 'core' tags were moved to use the
tag list instead of a core (i.e. always-there) pointer.

This may help with future work to reduce memory usage.

Signed-off-by: Simon Glass 
---

 cmd/dm.c | 23 ++
 drivers/core/Kconfig | 11 +++
 drivers/core/dump.c  | 73 
 drivers/core/tag.c   | 18 +++
 include/dm/root.h|  2 +-
 include/dm/tag.h |  8 +
 include/dm/util.h|  9 ++
 7 files changed, 143 insertions(+), 1 deletion(-)

Applied to u-boot-dm, thanks!

Re: [PATCH v3] powerpc: mpc85xx: Set TEXT_BASE addresses to real base values

[Tom Rini]

On Tue, Jun 28, 2022 at 11:18:34AM +0200, Pali Rohár wrote:
> On Thursday 23 June 2022 08:34:58 Tom Rini wrote:
> > On Thu, Jun 23, 2022 at 01:29:10PM +0200, Pali Rohár wrote:
> > > On Thursday 16 June 2022 14:19:44 Pali Rohár wrote:
> > > > Currently CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE addresses are
> > > > manually increased by 0x1000 due to .bootpg section. This section has 
> > > > size
> > > > of 0x1000 bytes and is manually put by linker script before .text 
> > > > section
> > > > (and therefore before base address) when CONFIG_SYS_MPC85XX_NO_RESETVEC 
> > > > is
> > > > set. Due to this fact lot of other config options are manually 
> > > > increased by
> > > > 0x1000 value to make correct layout. Note that entry point is not on
> > > > CONFIG_SPL_TEXT_BASE (image+0x1000) but it is really on address
> > > > CONFIG_SPL_TEXT_BASE-0x1000 (means at the start of the image).
> > > > 
> > > > Cleanup handling of .bootpg section when CONFIG_SYS_MPC85XX_NO_RESETVEC 
> > > > is
> > > > set. Put .bootpg code directly into .text section and move text base
> > > > address to the start of .bootpg code. And finally remove +0x1000 value 
> > > > from
> > > > lot of config options. With this removal custom PHDRS is not used 
> > > > anymore,
> > > > so remove it too.
> > > > 
> > > > After this change entry point would be at CONFIG_SPL_TEXT_BASE and not 
> > > > at
> > > > address -0x1000 anymore.
> > > > 
> > > > Tested on P2020 board with SPL and proper U-Boot.
> > > > 
> > > > Signed-off-by: Pali Rohár 
> > > > ---
> > > 
> > > PING???
> > > 
> > 
> > Yes, I thought this was part of fsl-qoriq-2022-6-20-v2 but I see it is
> > not.  I really don't want to see this have problems to apply, again.
> > But it probably will if it's not picked up pretty much now.  Peng,
> > should I grab this for next?  Otherwise someone is going to need to grab
> > this, edit and recountdiff it for it to apply as it's really not fair to
> > ask Pali to rebase it yet again if it doesn't and git also doesn't
> > handle it on a rebase.
> 
> Hm... So how to process this?

It's already not applying cleanly, so I've re-applied it and I'm putting
it through CI (along with some aspeed fixes) right now.  It should end
up in next later today.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 6/9] dm: core: Support accessing core tags

[Simon Glass]

Hi Simon,

On Sun, May 08, 2022 at 04:39:24AM -0600, Simon Glass wrote:
> At present tag numbers are only allocated for non-core data, meaning that
> the 'core' data, like priv and plat, are accessed through dedicated
> functions.
>
> For debugging and consistency it is convenient to use tags for this 'core'
> data too. Add support for this, with new tag numbers and functions to
> access the pointer and size for each.
>
> Update one of the test drivers so that the uclass-private data can be
> tested here.
>
> There is some code duplication with functions like device_alloc_priv() but
> this is not addressed for now. At some point, some rationalisation may
> help to reduce code size, but more thought it needed on that.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/core/device.c   | 65 +
>  drivers/misc/test_drv.c |  4 ++-
>  include/dm/device.h | 25 +
>  include/dm/tag.h| 13 ++-
>  test/dm/core.c  | 80 +
>  tools/dtoc/test_dtoc.py |  4 +++
>  6 files changed, 189 insertions(+), 2 deletions(-)
>
Applied to u-boot-dm, thanks!

Re: [PATCH] sandbox: usb: Fix out-of-bounds read when fd=-1

[Simon Glass]

Hi Sean,

On Wed, 23 Mar 2022 at 16:24, Sean Anderson  wrote:
>
> sandbox_flash_bulk uses priv->read_len to determine if priv->buff contains
> the response data (such as from SCSI_INQUIRY). However, if priv->fd=-1 in
> handle_read, then priv->read_len is not set even though we are going to
> PHASE_DATA. This causes sandbox_flash_bulk to try and read len bytes from
> priv->buff, which likely goes past the end of the buffer. Fix this by always
> setting priv->read_len even if we aren't going to read anything.
>
> Fixes: f4f715360c ("dm: usb: sandbox: Add an emulator for USB flash devices")
> Signed-off-by: Sean Anderson 
> ---
> Is returning -EIO correct here? Should we return 0 (nothing read)? Or pretend 
> to
> read the whole thing and then let the caller figure it out based on the 
> status?

It looks like returning an error makes sense, but Marek may know more.

>
>  drivers/usb/emul/sandbox_flash.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

>
Applied to u-boot-dm, thanks!

Re: [PATCH 1/5] patman: test_util: Fix printing results for failed tests

[Simon Glass]

On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak  wrote:
>
> When printing a python tool's test results, the entire list of failed
> tests and their tracebacks are reprinted for every failed test. This
> makes the test output quite unreadable. Fix the loop to print failures
> and tracebacks one at a time.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
>
>  tools/patman/test_util.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 2/5] patman: test_util: Handle nonexistent tests while loading tests

[Simon Glass]

On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak  wrote:
>
> It's possible to request a specific test to run when trying to run a
> python tool's tests. If we request a nonexistent test, the unittest
> loaders generate a fake test that reports this as an error. However, we
> get these fake tests even when the test exists, because test_util can
> load tests from multiple places one by one and the test we want only
> exists in one.
>
> The test_util helpers currently remove these fake tests when printing
> test results, but that's more of a workaround than a proper solution.
> Instead, don't even try to load the missing tests.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
>
>  tools/patman/test_util.py | 21 +
>  1 file changed, 5 insertions(+), 16 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 5/5] patman: test_util: Print test stdout/stderr within test summaries

[Simon Glass]

On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak  wrote:
>
> While running tests for a python tool, the tests' outputs get printed in
> whatever order they happen to run, without any indication as to which
> output belongs to which test. Unittest supports capturing these outputs
> and printing them as part of the test summaries, but when a failure or
> error occurs it switches back to printing as the tests run. Testtools
> and subunit tests can do the same as their parts inherit from unittest,
> but they don't outright expose this functionality.
>
> On the unittest side, enable output buffering for the custom test result
> class. Try to avoid ugly outputs by not printing stdout/stderr before
> the test summary for low verbosity levels and for successful tests.
>
> On the subunit side, implement a custom TestProtocolClient that enables
> the same underlying functionality and injects the captured streams as
> additional test details. This causes them to be merged into their test's
> error traceback message, which is later rebuilt into an exception and
> passed to our unittest report class.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
> The way I had to do this for concurrencytest feels hacky, so I am
> ambivalent towards this patch. I'm actually fine with re-running a
> failing binman test alone with --debug -v6 to get better, isolated
> output from it.

Yes that's what I tend to do, but I think we should try this patch. We
can always drop it in a future release if it causes problems.

>
>  tools/concurrencytest/concurrencytest.py | 83 +++-
>  tools/patman/test_util.py| 33 +-
>  2 files changed, 112 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 2/2] sandbox: show error if the device-tree cannot be loaded

[Simon Glass]

U-Boot's printf() used before setting up U-Boot's serial driver does not
create any output. Use os_printf() for error messages related to loading
the device-tree.

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/cpu/cpu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 1/1] sandbox: raise SANDBOX_RAM_SIZE_MB default to 256

[Simon Glass]

The UEFI Self Certification Test (SCT) cannot run on 128 MiB.

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 1/1] dm: fix formatting of uclass dump

[Simon Glass]

Insert an empty line after each uclass independent of whether it has
devices or not.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/core/dump.c | 2 --
 1 file changed, 2 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 1/2] sandbox: add function os_printf()

[Simon Glass]

Before setting up the devices U-Boot's printf() function cannot be used
for console output. Provide function os_printf() to print to stderr.

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/cpu/os.c | 13 +
 include/os.h  |  7 +++
 2 files changed, 20 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH] test: fix some pylint errors in test_bind.py

[Simon Glass]

* Use spaces not tabs
* Limit lines to 100 spaces
* Remove an unused import
* Sort imports correctly
* Add a module description

Signed-off-by: Heinrich Schuchardt 
---
 test/py/tests/test_bind.py | 345 +++--
 1 file changed, 175 insertions(+), 170 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 4/9] dm: core: Add documentation for the dm command

[Simon Glass]

Add a description and examples for the dm subcommands.

Signed-off-by: Simon Glass 
---

 doc/usage/cmd/dm.rst | 487 +++
 doc/usage/index.rst  |   1 +
 2 files changed, 488 insertions(+)
 create mode 100644 doc/usage/cmd/dm.rst

Applied to u-boot-dm, thanks!

Re: [PATCH v2 3/8] spl: binman: Declare extern symbols for VPL as well

[Simon Glass]

The binman extern symbol declarations in spl.h are missing the VPL
symbols recently added to spl.c, add them like the others.

Signed-off-by: Alper Nebi Yasak 
---

(no changes since v1)

 include/spl.h | 2 ++
 1 file changed, 2 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH 5/9] dm: core: Switch the testbus driver to use a new struct

[Simon Glass]

At present this driver uses 'priv' struct to hold 'plat' data, which is
confusing. The contents of the strct don't matter, since only dtoc is
using it. Create a new struct with the correct name.

Signed-off-by: Simon Glass 
---

 drivers/misc/test_drv.c | 2 +-
 include/dm/test.h   | 7 +++
 tools/dtoc/test_dtoc.py | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH v2 1/8] spl: binman: Fix use of undeclared u_boot_any symbols

[Simon Glass]

Some SPL functions directly use the binman 'u_boot_any' symbols to get
U-Boot's binman image position. These symbols are declared by the
SPL/TPL_BINMAN_SYMBOLS configs, but they are accessed by macros defined
by just CONFIG_BINMAN. So when BINMAN is enabled and BINMAN_SYMBOLS is
disabled, the code tries to use undeclared symbols and we get an error.

Therefore, any use of 'u_boot_any' symbols in the code is an implicit
dependency on SPL/TPL_BINMAN_SYMBOLS. However, in the current uses
they are meant to be the next phase's values, where that happens to be
U-Boot. In the meantime, helper funcions spl_get_image_pos/size() were
introduced to get these values.

Convert all uses of u_boot_any symbols to these functions, so we only
access these symbols at one place. Make sure they will not use these
symbols when the BINMAN_SYMBOLS configs are disabled, by returning early
in those cases.

Signed-off-by: Alper Nebi Yasak 
---

(no changes since v1)

 common/spl/spl.c | 10 +++---
 common/spl/spl_ram.c |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 7/9] dm: core: Add a way to collect memory usage

[Simon Glass]

Add a function for collecting the amount of memory used by driver model,
including devices, uclasses and attached data and tags.

This information can provide insights into how to reduce the memory
required by driver model. Future work may look at execution speed also.

Signed-off-by: Simon Glass 
---

 drivers/core/root.c | 53 +
 drivers/core/tag.c  | 11 ++
 include/dm/root.h   | 45 ++
 include/dm/tag.h| 11 ++
 test/dm/core.c  | 11 ++
 5 files changed, 131 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH 9/9] dm: spl: Allow SPL to show memory usage

[Simon Glass]

Add an option to tell SPL to show memory usage for driver model just
before it boots into the next phase.

Signed-off-by: Simon Glass 
---

 common/spl/spl.c |  9 +
 drivers/core/Kconfig | 10 ++
 2 files changed, 19 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH v2 2/8] spl: binman: Make TPL_BINMAN_SYMBOLS depend on TPL_FRAMEWORK

[Simon Glass]

TPL_BINMAN_SYMBOLS depends on SPL_FRAMEWORK. The code this enables is
compiled by checking CONFIG_$(SPL_TPL_)FRAMEWORK, so it should depend on
TPL_FRAMEWORK instead (which in turn depends on SPL_FRAMEWORK). This was
most likely a typo due to copy-pasting the config's SPL version, fix it.

Signed-off-by: Alper Nebi Yasak 
---

(no changes since v1)

 common/spl/Kconfig.tpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm, thanks!

Re: [PATCH v2 4/8] spl: binman: Split binman symbols support from enabling binman

[Simon Glass]

Enabling CONFIG_BINMAN makes binman run after a build to package any
images specified in the device-tree. It also enables a mechanism for
SPL/TPL to declare and use special linker symbols that refer to other
entries in the same binman image. A similar feature that gets this info
from the device-tree exists for U-Boot proper, but it is gated behind a
CONFIG_BINMAN_FDT unlike the symbols.

Confusingly, CONFIG_SPL/TPL_BINMAN_SYMBOLS also exist. These configs
don't actually enable/disable the symbols mechanism as one would expect,
but declare some symbols for U-Boot using this mechanism.

Reuse the BINMAN_SYMBOLS configs to make them toggle the symbols
mechanism, and declare symbols for the U-Boot phases in a dependent
BINMAN_UBOOT_SYMBOLS config. Extend it to cover symbols of all phases.
Update the config prompt and help message to make it clearer about this.
Fix binman test binaries to work with CONFIG_IS_ENABLED(BINMAN_SYMBOLS).

Co-developed-by: Peng Fan 
[Alper: New config for phase symbols, update Kconfigs, commit message]
Signed-off-by: Alper Nebi Yasak 
---
See Peng's patch [1] included in these changes.

[1] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)
https://lore.kernel.org/u-boot/20220603071715.15212-8-peng@oss.nxp.com/

Changes in v2:
- Split binman symbols support from enabling binman
- Move U-Boot phase symbol declarations to BINMAN_UBOOT_SYMBOLS configs
- Merge in Peng's patch for binman_sym.h changes

 common/spl/Kconfig  | 22 ++-
 common/spl/Kconfig.tpl  | 24 +++--
 common/spl/spl.c|  9 
 include/binman_sym.h|  6 +++---
 tools/binman/test/Makefile  |  2 +-
 tools/binman/test/generated/autoconf.h  |  3 +++
 tools/binman/test/u_boot_binman_syms.c  |  2 +-
 tools/binman/test/u_boot_binman_syms_size.c |  2 +-
 8 files changed, 49 insertions(+), 21 deletions(-)
 create mode 100644 tools/binman/test/generated/autoconf.h

Applied to u-boot-dm, thanks!

Re: [PATCH 3/5] patman: test_util: Use unittest text runner to print test results

[Simon Glass]

On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak  wrote:
>
> The python tools' test utilities handle printing test results, but the
> output is quite bare compared to an ordinary unittest run. Delegate
> printing the results to a unittest text runner, which gives us niceties
> like clear separation between each test's result and how long it took to
> run the test suite.
>
> Unfortunately it does not print info for skipped tests by default, but
> this can be handled later by a custom test result subclass. It also does
> not print the tool name; manually print a heading that includes the
> toolname so that the outputs of each tool's tests are distinguishable in
> the CI output.
>
> Signed-off-by: Alper Nebi Yasak 
> ---
>
>  tools/binman/main.py  |  8 ++
>  tools/buildman/main.py|  8 ++
>  tools/dtoc/main.py|  9 +++---
>  tools/dtoc/test_fdt.py|  8 +++---
>  tools/patman/main.py  |  8 ++
>  tools/patman/test_util.py | 58 ++-
>  6 files changed, 38 insertions(+), 61 deletions(-)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 1/1] sandbox: cast to pointer from integer of different size

[Simon Glass]

On Sun, Jun 12, 2022 at 7:25 PM Heinrich Schuchardt  wrote:
>
> Building sandbox_defconfig on ARMv7 with HOST_32BIT=y results in:
>
> drivers/misc/qfw_sandbox.c:51:25: warning:
> cast to pointer from integer of different size [-Wint-to-pointer-cast]
>51 | void *address = (void *)be64_to_cpu(dma->address);
>
> Add the missing type conversion.
>
> Fixes: 69512551aa84 ("test: qemu: add qfw sandbox driver, dm tests, qemu 
> tests")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/misc/qfw_sandbox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

Applied to u-boot-dm, thanks!

Re: [PATCH v2 5/8] spl: binman: Add config options for binman symbols in VPL

[Simon Glass]

The SPL code declares binman symbols for U-Boot phases depending on
CONFIG_IS_ENABLED(BINMAN_UBOOT_SYMBOLS). This config exists for SPL and
TPL, also add a version for VPL.

Signed-off-by: Alper Nebi Yasak 
---

Changes in v2:
- Update VPL configs for the new BINMAN_UBOOT_SYMBOLS

 common/spl/Kconfig.vpl | 24 
 1 file changed, 24 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH v2 7/8] spl: binman: Disable u_boot_any symbols for i.MX8M boards

[Simon Glass]

The i.MX8M boards use partially specified binman images which have an
SPL entry without a U-Boot entry. This would normally cause an error due
to the 'u_boot_any' binman symbols declared by BINMAN_UBOOT_SYMBOLS
requiring a U-Boot-like entry in the same image as the SPL.

However, a problem in the ARMv8 __image_copy_start symbol definition
effectively disables binman from attempting to write any symbols at all,
so everything appears to work fine until runtime. A future patch fixes
the issue in the linker scripts, which lets binman fill in the symbols,
which would result in the build error described above.

Explicitly disable the 'u_boot_any' symbols for i.MX8M boards. They are
already effectively unusable, and they are incompatible with the boards'
current binman image descriptions.

Signed-off-by: Alper Nebi Yasak 
---

Changes in v2:
- Add new patch to disable u_boot_any symbols for i.MX8M boards

 common/spl/Kconfig | 1 +
 common/spl/Kconfig.tpl | 1 +
 common/spl/Kconfig.vpl | 1 +
 3 files changed, 3 insertions(+)

Applied to u-boot-dm, thanks!