Re: [PATCH 0/4] Enable gigadevice and add new part #s

2023-01-04 Thread Michal Simek




On 1/4/23 19:50, Vlim wrote:

Thanks, Michal,

Thanks for the feedback.

I do have some questions regarding the following comments,

Second. When I run this

for i in `ls configs/xilinx_*`; do NAME=`basename $i`; echo $NAME; make $NAME;
make savedefconfig; cp defconfig $i; done

I see that locations your added entries are not correct.

Third b4 am -g is showing that base is not upstream version.
Please use next branch as base.


Simply base your patches on upstream git repository not u-boot-xlnx.
Use https://source.denx.de/u-boot/u-boot
master or next branch. (next branch is preferred now for upcoming one week or 
so).



Regarding the location of the entry, I believe you want me to add the entry in 
the alphabetical order?


Not really. I want to you follow Kconfig layout which is what make savedefconfig 
&& cp defconfig configs/ is for.




Also, for top posting, I am still not fully understood.
It seems like I should not include the previous email.
Let me try it here see if it is correct.


Just put reaction below things you want to comment as I do here.

Thanks,
Michal


[PATCH v3 3/3] eficonfig: add vertical scroll support

2023-01-04 Thread Masahisa Kojima
The current eficonfig menu does not support vertical scroll,
so it can not display the menu entries greater than
the console row size.

This commit add the vertial scroll support.
The console size is retrieved by
SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() service, then
calculates the row size for menu entry by subtracting
menu header and description row size from the console row size.
"start" and "end" are added in the efimenu structure.
"start" keeps the menu entry index at the top, "end" keeps
the bottom menu entry index. item_data_print() menu function
only draws the menu entry between "start" and "end".

Signed-off-by: Masahisa Kojima 
---
No update since v1

 cmd/eficonfig.c  | 79 
 include/efi_config.h |  4 +++
 include/efi_loader.h |  1 +
 3 files changed, 70 insertions(+), 14 deletions(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 6d5ebc4055..bf765a239b 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -29,8 +29,13 @@ static const char *eficonfig_change_boot_order_desc =
"  Press SPACE to activate or deactivate the entry\n"
"  Select [Save] to complete, ESC/CTRL+C to quit";
 
+static struct efi_simple_text_output_protocol *cout;
+static int avail_row;
+
 #define EFICONFIG_DESCRIPTION_MAX 32
 #define EFICONFIG_OPTIONAL_DATA_MAX 64
+#define EFICONFIG_MENU_HEADER_ROW_NUM 3
+#define EFICONFIG_MENU_DESC_ROW_NUM 5
 
 /**
  * struct eficonfig_filepath_info - structure to be used to store file path
@@ -156,18 +161,16 @@ void eficonfig_print_entry(void *data)
struct eficonfig_entry *entry = data;
bool reverse = (entry->efi_menu->active == entry->num);
 
-   /* TODO: support scroll or page for many entries */
+   if (entry->efi_menu->start > entry->num || entry->efi_menu->end < 
entry->num)
+   return;
 
-   /*
-* Move cursor to line where the entry will be drawn (entry->num)
-* First 3 lines(menu header) + 1 empty line
-*/
-   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
+   printf(ANSI_CURSOR_POSITION, (entry->num - entry->efi_menu->start) +
+  EFICONFIG_MENU_HEADER_ROW_NUM + 1, 7);
 
if (reverse)
puts(ANSI_COLOR_REVERSE);
 
-   printf("%s", entry->title);
+   printf(ANSI_CLEAR_LINE "%s", entry->title);
 
if (reverse)
puts(ANSI_COLOR_RESET);
@@ -190,8 +193,8 @@ void eficonfig_display_statusline(struct menu *m)
   ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
   "%s"
   ANSI_CLEAR_LINE_TO_END,
-  1, 1, entry->efi_menu->menu_header, entry->efi_menu->count + 5, 
1,
-  entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc);
+  1, 1, entry->efi_menu->menu_header, avail_row + 4, 1,
+  avail_row + 5, 1, entry->efi_menu->menu_desc);
 }
 
 /**
@@ -213,13 +216,23 @@ char *eficonfig_choice_entry(void *data)
 
switch (key) {
case KEY_UP:
-   if (efi_menu->active > 0)
+   if (efi_menu->active > 0) {
--efi_menu->active;
+   if (efi_menu->start > efi_menu->active) {
+   efi_menu->start--;
+   efi_menu->end--;
+   }
+   }
/* no menu key selected, regenerate menu */
return NULL;
case KEY_DOWN:
-   if (efi_menu->active < efi_menu->count - 1)
+   if (efi_menu->active < efi_menu->count - 1) {
++efi_menu->active;
+   if (efi_menu->end < efi_menu->active) {
+   efi_menu->start++;
+   efi_menu->end++;
+   }
+   }
/* no menu key selected, regenerate menu */
return NULL;
case KEY_SELECT:
@@ -399,6 +412,8 @@ efi_status_t eficonfig_process_common(struct efimenu 
*efi_menu,
 
efi_menu->delay = -1;
efi_menu->active = 0;
+   efi_menu->start = 0;
+   efi_menu->end = avail_row - 1;
 
if (menu_header) {
efi_menu->menu_header = strdup(menu_header);
@@ -1865,7 +1880,11 @@ static void eficonfig_print_change_boot_order_entry(void 
*data)
struct eficonfig_entry *entry = data;
bool reverse = (entry->efi_menu->active == entry->num);
 
-   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
+   if (entry->efi_menu->start > entry->num || entry->efi_menu->end < 
entry->num)
+   return;
+
+   printf(ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
+  (entry->num - entry->efi_menu->start) + 
EFICONFIG_MENU_HEADER_ROW_NUM + 1, 7);
 
if (reverse)
   

[PATCH v3 2/3] eficonfig: refactor change boot order implementation

2023-01-04 Thread Masahisa Kojima
This commit removes the change boot order specific
menu implementation. The change boot order implementation
calls eficonfig_process_common() same as other menus.

The change boot order menu requires own item_data_print
and item_choice implementation, but display_statusline
function can be a same function as other menus.

Signed-off-by: Masahisa Kojima 
Acked-by: Ilias Apalodimas 
---
Changes in v3:
- modify "reverse" local variable type to bool

Changes in v2:
- add comment when the user key press is not valid
- add const qualifier to eficonfig_change_boot_order_desc

 cmd/eficonfig.c | 245 +---
 1 file changed, 150 insertions(+), 95 deletions(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 274526fe20..6d5ebc4055 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -24,6 +24,11 @@ static struct efi_simple_text_input_protocol *cin;
 const char *eficonfig_menu_desc =
"  Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit";
 
+static const char *eficonfig_change_boot_order_desc =
+   "  Press UP/DOWN to move, +/- to change orde\n"
+   "  Press SPACE to activate or deactivate the entry\n"
+   "  Select [Save] to complete, ESC/CTRL+C to quit";
+
 #define EFICONFIG_DESCRIPTION_MAX 32
 #define EFICONFIG_OPTIONAL_DATA_MAX 64
 
@@ -105,6 +110,17 @@ struct eficonfig_boot_order_data {
bool active;
 };
 
+/**
+ * struct eficonfig_save_boot_order_data - structure to be used to change boot 
order
+ *
+ * @efi_menu:  pointer to efimenu structure
+ * @selected:  flag to indicate user selects "Save" entry
+ */
+struct eficonfig_save_boot_order_data {
+   struct efimenu *efi_menu;
+   bool selected;
+};
+
 /**
  * eficonfig_print_msg() - print message
  *
@@ -173,10 +189,9 @@ void eficonfig_display_statusline(struct menu *m)
  "\n%s\n"
   ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
   "%s"
-  ANSI_CLEAR_LINE_TO_END ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
+  ANSI_CLEAR_LINE_TO_END,
   1, 1, entry->efi_menu->menu_header, entry->efi_menu->count + 5, 
1,
-  entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc,
-  entry->efi_menu->count + 7, 1);
+  entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc);
 }
 
 /**
@@ -1841,63 +1856,44 @@ out:
 }
 
 /**
- * eficonfig_display_change_boot_order() - display the BootOrder list
+ * eficonfig_print_change_boot_order_entry() - print the boot option entry
  *
- * @efi_menu:  pointer to the efimenu structure
- * Return: status code
+ * @data:  pointer to the data associated with each menu entry
  */
-static void eficonfig_display_change_boot_order(struct efimenu *efi_menu)
+static void eficonfig_print_change_boot_order_entry(void *data)
 {
-   bool reverse;
-   struct list_head *pos, *n;
-   struct eficonfig_entry *entry;
-
-   printf(ANSI_CLEAR_CONSOLE ANSI_CURSOR_POSITION
-  "\n  ** Change Boot Order **\n"
-  ANSI_CURSOR_POSITION
-  "  Press UP/DOWN to move, +/- to change order"
-  ANSI_CURSOR_POSITION
-  "  Press SPACE to activate or deactivate the entry"
-  ANSI_CURSOR_POSITION
-  "  Select [Save] to complete, ESC/CTRL+C to quit"
-  ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
-  1, 1, efi_menu->count + 5, 1, efi_menu->count + 6, 1,
-  efi_menu->count + 7, 1,  efi_menu->count + 8, 1);
-
-   /* draw boot option list */
-   list_for_each_safe(pos, n, _menu->list) {
-   entry = list_entry(pos, struct eficonfig_entry, list);
-   reverse = (entry->num == efi_menu->active);
+   struct eficonfig_entry *entry = data;
+   bool reverse = (entry->efi_menu->active == entry->num);
 
-   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
+   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
 
-   if (reverse)
-   puts(ANSI_COLOR_REVERSE);
+   if (reverse)
+   puts(ANSI_COLOR_REVERSE);
 
-   if (entry->num < efi_menu->count - 2) {
-   if (((struct eficonfig_boot_order_data 
*)entry->data)->active)
-   printf("[*]  ");
-   else
-   printf("[ ]  ");
-   }
+   if (entry->num < entry->efi_menu->count - 2) {
+   if (((struct eficonfig_boot_order_data *)entry->data)->active)
+   printf("[*]  ");
+   else
+   printf("[ ]  ");
+   }
 
-   printf("%s", entry->title);
+   printf("%s", entry->title);
 
-   if (reverse)
-   puts(ANSI_COLOR_RESET);
-   }
+   if (reverse)
+   puts(ANSI_COLOR_RESET);
 }
 
 /**
- * eficonfig_choice_change_boot_order() - handle the BootOrder update
+ * 

[PATCH v3 1/3] eficonfig: refactor eficonfig_process_common function

2023-01-04 Thread Masahisa Kojima
Current change boot order implementation does not call
eficonfig_process_common() and call own menu functions
for display_statusline, item_data_print and item_choice.
Change boot order functionality should call
eficonfig_process_common() to improve maintenanceability.

This commit is a preparation to remove the change boot
order specific implementation. The menu functions
(display_statusline, item_data_print and item_choice) are
added as argument of eficonfig_process_common().
The menu description string displayed at the bottom of
the menu is also added as argument.

Signed-off-by: Masahisa Kojima 
---
Changes in v3:
- modify "reverse" local variable type to bool

Changes in v2:
- add const qualifier to eficonfig_menu_desc, change it to pointer

 cmd/eficonfig.c   | 71 +--
 cmd/eficonfig_sbkey.c | 18 +--
 include/efi_config.h  | 13 +++-
 3 files changed, 82 insertions(+), 20 deletions(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index ce7175a566..274526fe20 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -21,6 +21,8 @@
 #include 
 
 static struct efi_simple_text_input_protocol *cin;
+const char *eficonfig_menu_desc =
+   "  Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit";
 
 #define EFICONFIG_DESCRIPTION_MAX 32
 #define EFICONFIG_OPTIONAL_DATA_MAX 64
@@ -133,10 +135,10 @@ void eficonfig_print_msg(char *msg)
  *
  * @data:  pointer to the data associated with each menu entry
  */
-static void eficonfig_print_entry(void *data)
+void eficonfig_print_entry(void *data)
 {
struct eficonfig_entry *entry = data;
-   int reverse = (entry->efi_menu->active == entry->num);
+   bool reverse = (entry->efi_menu->active == entry->num);
 
/* TODO: support scroll or page for many entries */
 
@@ -160,7 +162,7 @@ static void eficonfig_print_entry(void *data)
  *
  * @m: pointer to the menu structure
  */
-static void eficonfig_display_statusline(struct menu *m)
+void eficonfig_display_statusline(struct menu *m)
 {
struct eficonfig_entry *entry;
 
@@ -170,10 +172,11 @@ static void eficonfig_display_statusline(struct menu *m)
printf(ANSI_CURSOR_POSITION
  "\n%s\n"
   ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
-  "  Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit"
+  "%s"
   ANSI_CLEAR_LINE_TO_END ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
   1, 1, entry->efi_menu->menu_header, entry->efi_menu->count + 5, 
1,
-  entry->efi_menu->count + 6, 1, entry->efi_menu->count + 7, 1);
+  entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc,
+  entry->efi_menu->count + 7, 1);
 }
 
 /**
@@ -182,7 +185,7 @@ static void eficonfig_display_statusline(struct menu *m)
  * @data:  pointer to the efimenu structure
  * Return: key string to identify the selected entry
  */
-static char *eficonfig_choice_entry(void *data)
+char *eficonfig_choice_entry(void *data)
 {
int esc = 0;
struct list_head *pos, *n;
@@ -358,9 +361,17 @@ out:
  *
  * @efi_menu:  pointer to the efimenu structure
  * @menu_header:   pointer to the menu header string
+ * @menu_desc: pointer to the menu description
+ * @display_statusline:function pointer to draw statusline
+ * @item_data_print:   function pointer to draw the menu item
+ * @item_choice:   function pointer to handle the key press
  * Return: status code
  */
-efi_status_t eficonfig_process_common(struct efimenu *efi_menu, char 
*menu_header)
+efi_status_t eficonfig_process_common(struct efimenu *efi_menu,
+ char *menu_header, const char *menu_desc,
+ void (*display_statusline)(struct menu *),
+ void (*item_data_print)(void *),
+ char *(*item_choice)(void *))
 {
struct menu *menu;
void *choice = NULL;
@@ -379,10 +390,11 @@ efi_status_t eficonfig_process_common(struct efimenu 
*efi_menu, char *menu_heade
if (!efi_menu->menu_header)
return EFI_OUT_OF_RESOURCES;
}
+   if (menu_desc)
+   efi_menu->menu_desc = menu_desc;
 
-   menu = menu_create(NULL, 0, 1, eficonfig_display_statusline,
-  eficonfig_print_entry, eficonfig_choice_entry,
-  efi_menu);
+   menu = menu_create(NULL, 0, 1, display_statusline, item_data_print,
+  item_choice, efi_menu);
if (!menu)
return EFI_INVALID_PARAMETER;
 
@@ -641,7 +653,12 @@ static efi_status_t eficonfig_select_volume(struct 
eficonfig_select_file_info *f
if (ret != EFI_SUCCESS)
goto out;
 
-   ret = eficonfig_process_common(efi_menu, "  ** Select Volume **");
+   ret = eficonfig_process_common(efi_menu, "  ** 

[PATCH v3 0/3] eficonfig: add vertical scroll support and refactoring

2023-01-04 Thread Masahisa Kojima
This series aims to add the vertical scroll for the eficonfig menu.
Before adding scroll support, this series does the refactoring
of change boot order implementation since it has own menu handling
and it should be removed to improve maintenanceability.

The eficonfig menu handles file selection for EFI load option
and secure boot keys, it likely to enumerate tens of files.
User can not select the file without scroll if theare are
many files under the target directory.

This series only modifies the eficonfig menus. Other menus
such as bootmenu is not yet done. We need to enhance the
U-Boot menu framework itself if we support other menus.

Masahisa Kojima (3):
  eficonfig: refactor eficonfig_process_common function
  eficonfig: refactor change boot order implementation
  eficonfig: add vertical scroll support

 cmd/eficonfig.c   | 385 +-
 cmd/eficonfig_sbkey.c |  18 +-
 include/efi_config.h  |  17 +-
 include/efi_loader.h  |   1 +
 4 files changed, 297 insertions(+), 124 deletions(-)

-- 
2.17.1



Re: [PATCH] rockchip: rk3328: Set VOP QoS to high priority

2023-01-04 Thread Kever Yang

Hi Nicolas,

    I can understand this change can fix the problem you have met.

    But this is likely a board specific setting instead of a soc 
platform setting, rockchip kernel have a qos dts node


to set to qos priority for different IP master and this can be customize 
for different board.



Thanks,

- Kever

On 2022/7/23 19:28, Nicolas Frattaroli wrote:

The default priority for the quality of service for the video
output results in unsightly glitches on the output whenever there
is memory pressure on the system, which happens a lot.

This sets the VOP QoS to high priority, which fixes this issue.

Signed-off-by: Nicolas Frattaroli 
---
  arch/arm/mach-rockchip/rk3328/rk3328.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c 
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index de17b88682..2373586b14 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -19,6 +19,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define GRF_BASE  0xFF10
  #define UART2_BASE0xFF13
  #define FW_DDR_CON_REG0xFF7C0040
+#define QOS_VOP_OFFSET 0xFF760080
+#define QOS_VOP_PRIORITY   0x8
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

[BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
@@ -54,6 +56,9 @@ int arch_cpu_init(void)
  
  	/* Disable the ddr secure region setting to make it non-secure */

rk_setreg(FW_DDR_CON_REG, 0x200);
+#else
+   printf("Setting VOP QoS\n");
+   rk_setreg(QOS_VOP_OFFSET + QOS_VOP_PRIORITY, 0x2);
  #endif
return 0;
  }


Re: [PATCH v5 1/6] rockchip: px30: fix possibly unused grf and cru variables

2023-01-04 Thread Kever Yang

Hi Quentin,

    Seems like this still not fix all the case for board ringneck-px30.

I got below error after I fix the CFG_IRAM_BASE:

   aarch64:  +   ringneck-px30
+/usr/lib/python3/dist-packages/setuptools/dist.py:473: UserWarning: 
Normalizing '2023.01' to '2023.1'

+  warnings.warn(
+In file included from drivers/serial/ns16550.c:13:0:
+include/ns16550.h:43:2: error: #error "Please define NS16550 registers 
size."

+ #error "Please define NS16550 registers size."
+  ^

Thanks,

- Kever

On 2023/1/3 21:26, Quentin Schulz wrote:

From: Quentin Schulz 

The grf and cru are only used when no UART base is provided by the user
(defaults to UART2) or for UART1, UART3 and UART5 to be used for the
debug UART. Therefore, let's surround those variable definitions with
the proper checks.

This wasn't an issue before support for UART0 was added, because all
cases were using cru and grf. UART0 only uses pmucru so there's a need
to not define those variables anymore.

Fixes: d0af506625ff ("rockchip: px30: support debug uart on UART0")
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  arch/arm/mach-rockchip/px30/px30.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index 0641e6af0f..35a36700df 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -297,8 +297,18 @@ void board_debug_uart_init(void)
CONFIG_DEBUG_UART_BASE == 0xff03)
static struct px30_pmugrf * const pmugrf = (void *)PMUGRF_BASE;
  #endif
+#if !defined(CONFIG_DEBUG_UART_BASE) || \
+   (CONFIG_DEBUG_UART_BASE != 0xff158000 && \
+CONFIG_DEBUG_UART_BASE != 0xff168000 && \
+CONFIG_DEBUG_UART_BASE != 0xff178000 && \
+CONFIG_DEBUG_UART_BASE != 0xff03) || \
+   (defined(CONFIG_DEBUG_UART_BASE) && \
+(CONFIG_DEBUG_UART_BASE == 0xff158000 || \
+ CONFIG_DEBUG_UART_BASE == 0xff168000 || \
+ CONFIG_DEBUG_UART_BASE == 0xff178000))
static struct px30_grf * const grf = (void *)GRF_BASE;
static struct px30_cru * const cru = (void *)CRU_BASE;
+#endif
  #if defined(CONFIG_DEBUG_UART_BASE) && CONFIG_DEBUG_UART_BASE == 0xff03
static struct px30_pmucru * const pmucru = (void *)PMUCRU_BASE;
  #endif



[PATCH] sunxi: f1c100s: Drop no-MMC hack

2023-01-04 Thread Andre Przywara
When support for the Allwinner F1C100s SoC was originally introduced,
its DT lacked any MMC nodes, which upset our sunxi-u-boot.dtsi overlay,
when it tried to add an alias to the SD card.  To quickly fix this back
then, we guarded that alias with a preprocessor macro.

Now the F1C100s family has gained MMC nodes, so we don't need the
special treatment anymore. Just remove this guard.

Signed-off-by: Andre Przywara 
---
 arch/arm/dts/sunxi-u-boot.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 2028d5b6a90..e959eb2a405 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -12,9 +12,7 @@
 
 / {
aliases {
-#ifndef CONFIG_MACH_SUNIV
mmc0 = 
-#endif
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
mmc1 = 
 #endif
-- 
2.35.5



[PATCH] sunxi: f1c100s: re-enable SYSRESET

2023-01-04 Thread Andre Przywara
The SoC .dtsi originally submitted for the Allwinner F1C100s had the
wrong compatible string for the watchdog, which broke U-Boot's reset
functionality. To quickly fix this, we disable CONFIG_SYSRESET in
cfcf1952c11e6ffcbbf88 ("sunxi: f1c100s: Drop SYSRESET to enable reset
functionality"), so that U-Boot's hardcoded reset driver could take over.

After this was properly fixed in the devicetree, we reverted that patch
in 92373de041ea ("Revert "sunxi: f1c100s: Drop SYSRESET to enable reset
functionality"), however this line sneaked back in with d0ee7f295d74
("Convert CONFIG_SYS_PBSIZE to Kconfig"), so during a Kconfig update.

Remove this line (again), to use the proper reset driver.

Fixes: d0ee7f295d74 ("Convert CONFIG_SYS_PBSIZE to Kconfig")
Signed-off-by: Andre Przywara 
---
Hi,

this is not critical (so nothing for 2023.01), reset works either way.
But we should fix it anyway.

Cheers,
Andre

 configs/licheepi_nano_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/licheepi_nano_defconfig b/configs/licheepi_nano_defconfig
index 12a43c1ec10..b25c9ba77cc 100644
--- a/configs/licheepi_nano_defconfig
+++ b/configs/licheepi_nano_defconfig
@@ -10,4 +10,3 @@ CONFIG_SPL_SPI_SUNXI=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_XTX=y
 CONFIG_SPI=y
-# CONFIG_SYSRESET is not set
-- 
2.35.5



[PATCH] sunxi: eMMC: support TOC0 on boot partitions

2023-01-04 Thread Andre Przywara
To determine whether we have been booted from an eMMC boot partition, we
replay some of the checks that the BROM must have done to successfully
load the SPL. This involves a checksum check, which currently relies on
the SPL being wrapped in an "eGON" header.

If a board has secure boot enabled, the BROM will only accept the "TOC0"
format, which is internally very different, but uses the same
checksumming algorithm. Actually the only difference for calculating the
checksum is that the size of the SPL is stored at a different offset.

Do a header check to determine whether we deal with an eGON or TOC0
format, then set the SPL size accordingly. The rest of the code is
unchanged.

This fixes booting from an eMMC boot partition on devices with secure
boot enabled, like the Remix Mini PC.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/board.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0c4b6dd1ca3..a90c88210cd 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -365,6 +365,7 @@ static bool sunxi_valid_emmc_boot(struct mmc *mmc)
struct blk_desc *bd = mmc_get_blk_desc(mmc);
u32 *buffer = (void *)(uintptr_t)CONFIG_TEXT_BASE;
struct boot_file_head *egon_head = (void *)buffer;
+   struct toc0_main_info *toc0_info = (void *)buffer;
int bootpart = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
uint32_t spl_size, emmc_checksum, chksum = 0;
ulong count;
@@ -391,11 +392,17 @@ static bool sunxi_valid_emmc_boot(struct mmc *mmc)
 
/* Read the first block to do some sanity checks on the eGON header. */
count = blk_dread(bd, 0, 1, buffer);
-   if (count != 1 || !sunxi_egon_valid(egon_head))
+   if (count != 1)
+   return false;
+
+   if (sunxi_egon_valid(egon_head))
+   spl_size = buffer[4];
+   else if (sunxi_toc0_valid(toc0_info))
+   spl_size = buffer[7];
+   else
return false;
 
/* Read the rest of the SPL now we know it's halfway sane. */
-   spl_size = buffer[4];
count = blk_dread(bd, 1, DIV_ROUND_UP(spl_size, bd->blksz) - 1,
  buffer + bd->blksz / 4);
 
-- 
2.35.5



Re: [PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY

2023-01-04 Thread Marek Vasut

On 1/4/23 19:05, Adam Ford wrote:

Due to the part shortage, the AR8031 PHY was replaced with a
Micrel KSZ9131. Enabling both config options keeps backward
compatibility with either platform, and both appear to be
auto-detected.


Reviewed-by: Marek Vasut 

(is this material for 2023.01 release or can this wait?)


[PATCH] distro_bootcmd: Fix copy-paste error

2023-01-04 Thread Marek Vasut
The "SCRIPT FAILED" string is copied from scan_dev_for_scripts script,
update it so it prints "EXTLINUX FAILED" instead in scan_dev_for_extlinux
script.

Signed-off-by: Marek Vasut 
---
Cc: Frieder Schrempf 
Cc: Matwey V. Kornilov 
Cc: Pali Rohar 
Cc: Peter Hoyes 
Cc: Tom Rini 
---
 include/config_distro_bootcmd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fcb319a20ae..c3a2414b914 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -484,7 +484,7 @@
"${prefix}${boot_syslinux_conf}; then "   \
"echo Found ${prefix}${boot_syslinux_conf}; " \
"run boot_extlinux; " \
-   "echo SCRIPT FAILED: continuing...; " \
+   "echo EXTLINUX FAILED: continuing...; "   \
"fi\0"\
\
"boot_a_script="  \
-- 
2.39.0



[PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again

2023-01-04 Thread Marek Vasut
Do not access gd->ram_size and assume this is actual valid RAM size. Since 
commit
777706b ("common/memsize.c: Fix get_effective_memsize() to check for 
overflow")
the RAM size may be less than gd->ram_size , call get_effective_memsize() to get
the limited value instead.

The aforementioned commit makes STM32MP15xx boards with 1 GiB of DRAM
at 0xc000 hang on boot, which is a grave defect.

Signed-off-by: Marek Vasut 
---
Cc: Pali Rohar 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Tom Rini 
---
 arch/arm/mach-stm32mp/dram_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/dram_init.c 
b/arch/arm/mach-stm32mp/dram_init.c
index 9346fa8546d..80ba5c27741 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -51,7 +51,7 @@ phys_size_t board_get_usable_ram_top(phys_size_t total_size)
 
/* found enough not-reserved memory to relocated U-Boot */
lmb_init();
-   lmb_add(, gd->ram_base, gd->ram_size);
+   lmb_add(, gd->ram_base, get_effective_memsize());
boot_fdt_add_mem_rsv_regions(, (void *)gd->fdt_blob);
/* add 8M for reserved memory for display, fdt, gd,... */
size = ALIGN(SZ_8M + CONFIG_SYS_MALLOC_LEN + total_size, 
MMU_SECTION_SIZE),
-- 
2.39.0



[PATCH] Revert "time: add weak annotation to timer_read_counter declaration"

2023-01-04 Thread Harald Seiler
This reverts commit 65ba7add0d609bbd035b8d42fafdaf428ac24751.

A weak extern is a nasty sight to behold: If the symbol is never
defined, on ARM, the linker will replace the function call with a NOP.
This behavior isn't well documented but there are at least some hints
to it [1].

When timer_read_counter() is not defined, this obviously does the wrong
thing here and it does so silently.  The consequence is that a board
without timer_read_counter() will sleep for random amounts and generally
have erratic get_ticks() values.

Drop the __weak annotation of the extern so a linker error is raised
when timer_read_counter() is not defined.  This is okay, the original
reason for the reverted change - breaking the sandbox build - no longer
applies.

Final sidenote:  This was the only weak extern in the entire tree at
this time as far as I can tell.  I guess we should avoid introduction of
them again as they are obviously a very big footgun.

[1]: 
https://stackoverflow.com/questions/31203402/gcc-behavior-for-unresolved-weak-functions

Fixes: 65ba7add0d60 ("time: add weak annotation to timer_read_counter 
declaration")
Reported-by: Serge Bazanski 
Signed-off-by: Harald Seiler 
---
 lib/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/time.c b/lib/time.c
index f3aaf472d1..1e24b1b03c 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -63,7 +63,7 @@ ulong timer_get_boot_us(void)
 }
 
 #else
-extern unsigned long __weak timer_read_counter(void);
+extern unsigned long timer_read_counter(void);
 #endif
 
 #if CONFIG_IS_ENABLED(TIMER)
-- 
2.39.0



Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-04 Thread Marek Vasut

On 1/5/23 00:48, Heinrich Schuchardt wrote:

Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :

On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt  wrote:


On 1/4/23 22:35, Adam Ford wrote:

ATF generates a couple memory nodes based on how it's compiled and
generates a reserved-memory node, and I want to overlay it with the
device tree so Linux knows about this reserved memory.

When I boot U-Boot, I can read the reserved-memory node:

=> fdt addr 0xe631e588
Working FDT set to e631e588
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
renesas,formats = <0x>;
no-map;
reg = <0x 0x5400 0x 0x0300>;
compatible = "renesas,lossy-decompression", "shared-dma-pool";
};
};
=>

I attempt to overlay it with the following:

=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $load_addr


When actually setting the address you will see a message "Working FDT
set to %lx\n". So I assume $load_addr is empty.

Did you mean $loadaddr or $fileaddr?


Opps, that was a copy-paste error.  Even with that, I still get the
failure to overlay:



Did you load a .dtbo file to apply? You cannot apply a devicetree.

Is the fdt that you want to apply the overlay to built with symbols (dtc 
parameter -@)?


Note that the fragment passed to U-Boot by upstream ATF is already 
automatically merged into the U-Boot control DT (see 
board/renesas/rcar-common/common.c ) . U-Boot should pass that on to 
Linux automatically.


Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-04 Thread Heinrich Schuchardt
Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
>On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt  wrote:
>>
>> On 1/4/23 22:35, Adam Ford wrote:
>> > ATF generates a couple memory nodes based on how it's compiled and
>> > generates a reserved-memory node, and I want to overlay it with the
>> > device tree so Linux knows about this reserved memory.
>> >
>> > When I boot U-Boot, I can read the reserved-memory node:
>> >
>> > => fdt addr 0xe631e588
>> > Working FDT set to e631e588
>> > => fdt print /reserved-memory
>> > reserved-memory {
>> > lossy-decompression@5400 {
>> > renesas,formats = <0x>;
>> > no-map;
>> > reg = <0x 0x5400 0x 0x0300>;
>> > compatible = "renesas,lossy-decompression", "shared-dma-pool";
>> > };
>> > };
>> > =>
>> >
>> > I attempt to overlay it with the following:
>> >
>> > => run loadfdt
>> > 65932 bytes read in 6 ms (10.5 MiB/s)
>> > => fdt addr $load_addr
>>
>> When actually setting the address you will see a message "Working FDT
>> set to %lx\n". So I assume $load_addr is empty.
>>
>> Did you mean $loadaddr or $fileaddr?
>
>Opps, that was a copy-paste error.  Even with that, I still get the
>failure to overlay:
>

Did you load a .dtbo file to apply? You cannot apply a devicetree.

Is the fdt that you want to apply the overlay to built with symbols (dtc 
parameter -@)?

Best regards

Heinrich 
>
>=> run loadfdt
>65932 bytes read in 6 ms (10.5 MiB/s)
>=> fdt addr $fdt_addr
>Working FDT set to 4800
>=> fdt resize 8192
>=> fdt apply 0xe631e588
>=> fdt print /reserved-memory
>libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
>=>
>
>
>
>>
>> > Working fdt: e631e588
>> > => fdt resize 8192
>> > => fdt apply 0xe631e588
>>
>> Here you are apply the devicetree at e631e588 to itself which cannot work.
>>
>> Best regards
>>
>> Heinrich
>>
>> >
>> > At this point, I would expect the reserved-memory node to be merged
>> > with the main FDT, but it appears to be missing.
>> >
>> > => fdt print /reserved-memory
>> > libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
>> > =>
>> >
>> > There are no errors, but there are no overlays either.
>> >
>> > Does someone have any suggestions as to what I am doing wrong?
>> > Without the reserved memory node, Linux can crash if it tries to use
>> > the memory in that restricted area, and that node might change
>> > depending on how ATF is compiled.
>> >
>> > Thanks for any help.
>> >
>> > adam
>>



Re: [PATCH 0/8] sunxi: Update H616 DRAM driver

2023-01-04 Thread Andre Przywara
On Wed, 04 Jan 2023 22:02:33 +0100
Jernej Škrabec  wrote:

Hi Jernej,

> Dne sreda, 04. januar 2023 ob 01:47:16 CET je Andre Przywara napisal(a):
> > On Sun, 11 Dec 2022 17:32:05 +0100
> > Jernej Skrabec  wrote:
> > 
> > Hi Jernej,
> >   
> > > Current H616 DRAM driver is completely customized to Orange Pi Zero2
> > > board, which is currently the only H616 board supported by U-Boot.
> > > Needless to say, this is not ideal for adding new boards. With changes
> > > in this series, all DDR3 boards are supported and all that is needed is
> > > just vendor DRAM values extracted from Android image. New DRAM types
> > > should also be easier to support, since a lot of constants used before
> > > are not really DRAM type dependent.
> > > 
> > > Changes were verified by decompiling driver and generated values were
> > > compared to previous, hard coded ones. This was done without dram_para
> > > structures, so compiler was able to heavily optimize code and produce
> > > constants.  
> > 
> > so many thanks again for putting this together!
> > I came to like (the idea of) this series very much lately, as this
> > removes timing/delay values from the code, and easily allows putting the
> > vendor provided values in the defconfig.
> > I used that approach as well for the D1 driver, and am wondering if we
> > should extend this to other SoCs, potentially unifying the Kconfig part?  
> 
> While it would be nice, I'm not sure it's worth the effort and there is a 
> chance that something might break during rework.

Fair enough, was just an idea.

> > And you hinted at a v2, can you provide an estimate for this? If you
> > send it still this week, I would like to put it into U-Boot's next
> > branch, otherwise it goes straight into master, should the merge window
> > open next week as planned.  
> 
> I have changes for v2 in my github repo. I don't have any estimation, since I 
> had some time off from programming lately

Sounds good!

> and I'm just only catching up. 
> Weekend at earliest, but no promises.

No worries, that was a genuine question, for my planning. I have plenty
of other things to do, and we have still plenty of time (till end of
January or so) to get things merged.

> > Btw., to verify the feasibility of drivers/ram/sunxi, I moved the H616
> > driver into there, together with the Kconfig parts, I wonder what you
> > think about this? An example of how this looks is in the D1 driver
> > patches.  
> 
> Looks good, but I don't know what are implications regarding interface. Is 
> just code move or that implies that some ram framework must be used?

I don't know what Simon and Tom will say, but I was cheekily just using
the directory, ignoring the current DM_SPL preference for code in
there. For the D1/T113s code this is probably a no-brainer, but
I also found it a nice and simple solution to declutter and cleanup
arch/arm/mach-sunxi and its Kconfig.
So yeah, it's just moving the files and Kconfig stanzas there, and
otherwise leaves the actual code untouched. We still call
sunxi_dram_init() from our legacy SPL code.

Cheers,
Andre


> 
> Best regards,
> Jernej
> 
> > 
> > Cheers,
> > Andre
> >   
> > > Please take a look.
> > > 
> > > Best regards,
> > > Jernej
> > > 
> > > Jernej Skrabec (8):
> > >   sunxi: Fix write to H616 DRAM CR register
> > >   sunxi: cosmetic: Fix H616 DRAM driver code style
> > >   sunxi: parameterize H616 DRAM ODT values
> > >   sunxi: Convert H616 DRAM options to single setting
> > >   sunxi: Always configure ODT on H616 DRAM
> > >   sunxi: Make bit delay function in H616 DRAM code void
> > >   sunxi: Parameterize bit delay code in H616 DRAM driver
> > >   sunxi: Parameterize H616 DRAM code some more
> > >  
> > >  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  18 +
> > >  arch/arm/mach-sunxi/Kconfig   |  67 +--
> > >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++---
> > >  configs/orangepi_zero2_defconfig  |   8 +-
> > >  4 files changed, 348 insertions(+), 190 deletions(-)  
> 
> 
> 
> 



Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-04 Thread Adam Ford
On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt  wrote:
>
> On 1/4/23 22:35, Adam Ford wrote:
> > ATF generates a couple memory nodes based on how it's compiled and
> > generates a reserved-memory node, and I want to overlay it with the
> > device tree so Linux knows about this reserved memory.
> >
> > When I boot U-Boot, I can read the reserved-memory node:
> >
> > => fdt addr 0xe631e588
> > Working FDT set to e631e588
> > => fdt print /reserved-memory
> > reserved-memory {
> > lossy-decompression@5400 {
> > renesas,formats = <0x>;
> > no-map;
> > reg = <0x 0x5400 0x 0x0300>;
> > compatible = "renesas,lossy-decompression", "shared-dma-pool";
> > };
> > };
> > =>
> >
> > I attempt to overlay it with the following:
> >
> > => run loadfdt
> > 65932 bytes read in 6 ms (10.5 MiB/s)
> > => fdt addr $load_addr
>
> When actually setting the address you will see a message "Working FDT
> set to %lx\n". So I assume $load_addr is empty.
>
> Did you mean $loadaddr or $fileaddr?

Opps, that was a copy-paste error.  Even with that, I still get the
failure to overlay:


=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $fdt_addr
Working FDT set to 4800
=> fdt resize 8192
=> fdt apply 0xe631e588
=> fdt print /reserved-memory
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
=>



>
> > Working fdt: e631e588
> > => fdt resize 8192
> > => fdt apply 0xe631e588
>
> Here you are apply the devicetree at e631e588 to itself which cannot work.
>
> Best regards
>
> Heinrich
>
> >
> > At this point, I would expect the reserved-memory node to be merged
> > with the main FDT, but it appears to be missing.
> >
> > => fdt print /reserved-memory
> > libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
> > =>
> >
> > There are no errors, but there are no overlays either.
> >
> > Does someone have any suggestions as to what I am doing wrong?
> > Without the reserved memory node, Linux can crash if it tries to use
> > the memory in that restricted area, and that node might change
> > depending on how ATF is compiled.
> >
> > Thanks for any help.
> >
> > adam
>


Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-04 Thread Heinrich Schuchardt

On 1/4/23 22:35, Adam Ford wrote:

ATF generates a couple memory nodes based on how it's compiled and
generates a reserved-memory node, and I want to overlay it with the
device tree so Linux knows about this reserved memory.

When I boot U-Boot, I can read the reserved-memory node:

=> fdt addr 0xe631e588
Working FDT set to e631e588
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
renesas,formats = <0x>;
no-map;
reg = <0x 0x5400 0x 0x0300>;
compatible = "renesas,lossy-decompression", "shared-dma-pool";
};
};
=>

I attempt to overlay it with the following:

=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $load_addr


When actually setting the address you will see a message "Working FDT
set to %lx\n". So I assume $load_addr is empty.

Did you mean $loadaddr or $fileaddr?


Working fdt: e631e588
=> fdt resize 8192
=> fdt apply 0xe631e588


Here you are apply the devicetree at e631e588 to itself which cannot work.

Best regards

Heinrich



At this point, I would expect the reserved-memory node to be merged
with the main FDT, but it appears to be missing.

=> fdt print /reserved-memory
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
=>

There are no errors, but there are no overlays either.

Does someone have any suggestions as to what I am doing wrong?
Without the reserved memory node, Linux can crash if it tries to use
the memory in that restricted area, and that node might change
depending on how ATF is compiled.

Thanks for any help.

adam




[PATCH 1/1] efi_loader: make .data section of *_efi.so files RW

2023-01-04 Thread Heinrich Schuchardt
When building with binutils 2.39 warnings

*_efi.so has a LOAD segment with RWX permissions

occur.

Use SHF_WRITE | SHF_ALLOC as section flags for the .data section.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/lib/elf_aarch64_efi.lds | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/elf_aarch64_efi.lds b/arch/arm/lib/elf_aarch64_efi.lds
index ffc6f6e604..3e3da47d6a 100644
--- a/arch/arm/lib/elf_aarch64_efi.lds
+++ b/arch/arm/lib/elf_aarch64_efi.lds
@@ -7,6 +7,12 @@
 
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
"elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+
+PHDRS
+{
+   data PT_LOAD FLAGS(3); /* SHF_WRITE | SHF_ALLOC */
+}
+
 ENTRY(_start)
 SECTIONS
 {
@@ -49,7 +55,7 @@ SECTIONS
. = ALIGN(512);
_bss_end = .;
_edata = .;
-   }
+   } :data
_data_size = _edata - _data;
.rela.dyn : { *(.rela.dyn) }
.rela.plt : { *(.rela.plt) }
-- 
2.37.2



Applying DTB Overlays from ATF on RZ/G2

2023-01-04 Thread Adam Ford
ATF generates a couple memory nodes based on how it's compiled and
generates a reserved-memory node, and I want to overlay it with the
device tree so Linux knows about this reserved memory.

When I boot U-Boot, I can read the reserved-memory node:

=> fdt addr 0xe631e588
Working FDT set to e631e588
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
renesas,formats = <0x>;
no-map;
reg = <0x 0x5400 0x 0x0300>;
compatible = "renesas,lossy-decompression", "shared-dma-pool";
};
};
=>

I attempt to overlay it with the following:

=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $load_addr
Working fdt: e631e588
=> fdt resize 8192
=> fdt apply 0xe631e588

At this point, I would expect the reserved-memory node to be merged
with the main FDT, but it appears to be missing.

=> fdt print /reserved-memory
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
=>

There are no errors, but there are no overlays either.

Does someone have any suggestions as to what I am doing wrong?
Without the reserved memory node, Linux can crash if it tries to use
the memory in that restricted area, and that node might change
depending on how ATF is compiled.

Thanks for any help.

adam


Re: [PATCH 8/8] sunxi: Parameterize H616 DRAM code some more

2023-01-04 Thread Jernej Škrabec
Dne sreda, 04. januar 2023 ob 01:38:12 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:13 +0100
> 
> Jernej Skrabec  wrote:
> > Part of the code, previously known as "unknown feature" also doesn't
> > have constant values. They are derived from TPR0 parameter in vendor
> > DRAM code. Introduce that parameter here too, to ease adding new boards.
> 
> That seems to also miss the value for the OPi Zero2 defconfig.

Again, Zero2 doesn't use all features.

> 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  1 +
> >  arch/arm/mach-sunxi/Kconfig   |  6 
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 35 +++
> >  3 files changed, 35 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > c7890c83391f..ff736bd88d10 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -158,6 +158,7 @@ struct dram_para {
> > 
> > u32 dx_dri;
> > u32 ca_dri;
> > u32 odt_en;
> > 
> > +   u32 tpr0;
> > 
> > u32 tpr10;
> > u32 tpr11;
> > u32 tpr12;
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index b050f0a56971..7858a7045f7e 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -73,6 +73,12 @@ config DRAM_SUN50I_H616_ODT_EN
> > 
> > help
> > 
> >   ODT EN value from vendor DRAM settings.
> > 
> > +config DRAM_SUN50I_H616_TPR0
> > +   hex "H616 DRAM TPR0 parameter"
> > +   default 0x0
> 
> Is 0x0 really a feasible default value? I'd suggest we don't provide a
> default, so force people to be prompted for a value, if nothing is in
> (a new board's) defconfig.

This is not used on all boards, so imo is ok to have it as default.

Best regards,
Jernej

> 
> The rest looks OK, though I can't really comment on the actual bits -
> but who can anyway ;-)
> 
> Cheers,
> Andre
> 
> > +   help
> > + TPR0 value from vendor DRAM settings.
> > +
> > 
> >  config DRAM_SUN50I_H616_TPR10
> >  
> > hex "H616 DRAM TPR10 parameter"
> > help
> > 
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index df06cea42464..6d8f8d371bfe
> > 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -808,15 +808,35 @@ static bool mctl_phy_init(struct dram_para *para)
> > 
> > writel(phy_init[i], [i]);
> > 
> > if (para->tpr10 & TPR10_UNKNOWN_FEAT0) {
> > 
> > +   if (para->tpr0 & BIT(30))
> > +   val = (para->tpr0 >> 7) & 0x3e;
> > +   else
> > +   val = (para->tpr10 >> 3) & 0x1e;
> > +
> > 
> > ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x780);
> > for (i = 0; i < 32; i++)
> > 
> > -   writel(0x16, [i]);
> > -   writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x78c);
> > -   writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> > -   writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> > -   writel(0x8, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> > -   writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> > -   writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> > +   writel(val, [i]);
> > +
> > +   val = (para->tpr10 << 1) & 0x1e;
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> > +
> > +   /* following configuration is DDR3 specific */
> > +   val = (para->tpr10 >> 7) & 0x1e;
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> > +   /*
> > +* TODO: Offsets 0x79c, 0x794 and 0x7e4 may need
> > +* to be set here. However, this doesn't seem to
> > +* be needed by any board seen in the wild for now.
> > +* It's not implemented because it would unnecessarily
> > +* introduce PARA2 and TPR2 options.
> > +*/
> > +   if (para->tpr0 & BIT(31)) {
> > +   val = (para->tpr0 << 1) & 0x3e;
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x78c);
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> > +   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> > +   }
> > 
> > }
> > 
> > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc);
> > 
> > @@ -1110,6 +1130,7 @@ unsigned long sunxi_dram_init(void)
> > 
> > .dx_dri = CONFIG_DRAM_SUN50I_H616_DX_DRI,
> > .ca_dri = CONFIG_DRAM_SUN50I_H616_CA_DRI,
> > .odt_en = CONFIG_DRAM_SUN50I_H616_ODT_EN,
> > 
> > +   .tpr0 = CONFIG_DRAM_SUN50I_H616_TPR0,
> > 
> > .tpr10 = CONFIG_DRAM_SUN50I_H616_TPR10,
> > .tpr11 = CONFIG_DRAM_SUN50I_H616_TPR11,
> > .tpr12 = CONFIG_DRAM_SUN50I_H616_TPR12,

Re: [PATCH 7/8] sunxi: Parameterize bit delay code in H616 DRAM driver

2023-01-04 Thread Jernej Škrabec
Dne sreda, 04. januar 2023 ob 01:37:47 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:12 +0100
> Jernej Skrabec  wrote:
> 
> Hi Jernej,
> 
> > These values are highly board specific and thus make sense to add
> > parameter for them. To ease adding support for new boards, let's make
> > them same as in vendor DRAM settings.
> 
> So scrolling up and down: does this patch miss the TPR11 and TPR12
> values in the OPi-Zero2 defconfig? 

No, because 0 (which is default) is correct here.

> And should we not default to 0 in
> Kconfig to help spotting this omission more easily for new boards?

Not all boards need to set all the values. I set default values for symbols 
which seem to have same value for multiple boards.

> If I pieced the bits together correctly, we end up with the same values
> in the register with TPR11=0xfffedddb and TPR12=0xeddca998, and ODT_EN
> being irrelevant.
> 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  .../include/asm/arch-sunxi/dram_sun50i_h616.h |   4 +
> >  arch/arm/mach-sunxi/Kconfig   |  18 ++
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 189 +-
> >  3 files changed, 162 insertions(+), 49 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > b5140c79b70e..c7890c83391f 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -145,6 +145,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> > 
> >  #define TPR10_READ_CALIBRATION BIT(21)
> >  #define TPR10_READ_TRAININGBIT(22)
> >  #define TPR10_WRITE_TRAINING   BIT(23)
> > 
> > +#define TPR10_UNKNOWN_FEAT3BIT(30)
> 
> As mentioned in the other patch: if we don't know the meaning of this
> bit, I'd prefer using BIT(30) directly, or at least encode BIT30
> in the name.
> 
> >  struct dram_para {
> >  
> > u32 clk;
> > 
> > @@ -156,7 +157,10 @@ struct dram_para {
> > 
> > u32 dx_odt;
> > u32 dx_dri;
> > u32 ca_dri;
> > 
> > +   u32 odt_en;
> > 
> > u32 tpr10;
> > 
> > +   u32 tpr11;
> > +   u32 tpr12;
> > 
> >  };
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 778304b77e26..b050f0a56971 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -67,11 +67,29 @@ config DRAM_SUN50I_H616_CA_DRI
> > 
> > help
> > 
> >   CA DRI value from vendor DRAM settings.
> > 
> > +config DRAM_SUN50I_H616_ODT_EN
> > +   hex "H616 DRAM ODT EN parameter"
> > +   default 0x1
> > +   help
> > + ODT EN value from vendor DRAM settings.
> > +
> > 
> >  config DRAM_SUN50I_H616_TPR10
> >  
> > hex "H616 DRAM TPR10 parameter"
> > help
> > 
> >   TPR10 value from vendor DRAM settings. It tells which features
> >   should be configured, like write leveling, read calibration, 
etc.
> > 
> > +
> > +config DRAM_SUN50I_H616_TPR11
> > +   hex "H616 DRAM TPR11 parameter"
> > +   default 0x0
> > +   help
> > + TPR11 value from vendor DRAM settings.
> > +
> > +config DRAM_SUN50I_H616_TPR12
> > +   hex "H616 DRAM TPR12 parameter"
> > +   default 0x0
> > +   help
> > + TPR12 value from vendor DRAM settings.
> > 
> >  endif
> >  
> >  config SUN6I_PRCM
> > 
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index 3b2ba168498c..df06cea42464
> > 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -574,7 +574,7 @@ static bool mctl_phy_write_training(struct dram_para
> > *para)> 
> >  static void mctl_phy_bit_delay_compensation(struct dram_para *para)
> >  {
> > 
> > -   u32 *ptr;
> > +   u32 *ptr, val;
> > 
> > int i;
> > 
> > if (para->tpr10 & TPR10_UNKNOWN_FEAT2) {
> > 
> > @@ -582,49 +582,93 @@ static void mctl_phy_bit_delay_compensation(struct
> > dram_para *para)> 
> > setbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 8);
> > clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 0x10);
> > 
> > +   if (para->tpr10 & TPR10_UNKNOWN_FEAT3)
> > +   val = para->tpr11 & 0x3f;
> > +   else
> > +   val = (para->tpr11 & 0xf) << 1;
> > +
> > 
> > ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x484);
> > for (i = 0; i < 9; i++) {
> > 
> > -   writel_relaxed(0x16, ptr);
> > -   writel_relaxed(0x16, ptr + 0x30);
> > +   writel_relaxed(val, ptr);
> > +   writel_relaxed(val, ptr + 0x30);
> > 
> > ptr += 2;
> > 
> > }
> > 
> > -   writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4d0);
> > -   writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x590);
> > -   writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4cc);
> > -   writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x58c);
> > +
> 

Re: [PATCH 5/8] sunxi: Always configure ODT on H616 DRAM

2023-01-04 Thread Jernej Škrabec
Dne sreda, 04. januar 2023 ob 01:37:17 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:10 +0100
> 
> Jernej Skrabec  wrote:
> > Vendor H616 DRAM code always configure part which we call ODT
> > configuration. Let's reflect that here too.
> 
> I wonder if we need this patch at all. "depends on !H616" looks
> counter-intuitive, since this suggests it's always off.

I don't see it that way. It just means it's unused for H616.

> As it stands, it doesn't hurt. "default y" does the right thing, and if
> people want to shoot themselves in the foot: fine by me.
> 
> At least I would like to keep the Kconfig part. We could change the
> condition in the code into an explaining comment, if you still want to
> force this on.
> 
> And coming back from patch 7/8: how does this correspond to
> DRAM_SUN50I_H616_ODT_EN?

The thing is that I can't give you good explanation for anything above due to 
nature of reverse engineering. It's just how vendor code is done and I would 
argue that my original assumption when I was writing this driver was wrong and 
I shouldn't use this symbol at all in first place. I'm not even sure if I named 
mctl_phy_configure_odt() completely correct. It has to do something with ODT, 
but I don't know if it gets enabled here or not. To me, it looks more like 
that just some parameters are set here.

Best regards,
Jernej

> 
> Cheers,
> Andre
> 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  arch/arm/mach-sunxi/Kconfig| 2 +-
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c | 3 +--
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index abcbd0fb9061..778304b77e26 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -488,12 +488,12 @@ config DRAM_ZQ
> > 
> >  config DRAM_ODT_EN
> >  
> > bool "sunxi dram odt enable"
> > 
> > +   depends on !MACH_SUN50I_H616
> > 
> > default y if MACH_SUN8I_A23
> > default y if MACH_SUNXI_H3_H5
> > default y if MACH_SUN8I_R40
> > default y if MACH_SUN50I
> > default y if MACH_SUN50I_H6
> > 
> > -   default y if MACH_SUN50I_H616
> > 
> > ---help---
> > Select this to enable dram odt (on die termination).
> > 
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index 14a01a3c4e54..bf5b4ddfb5c2
> > 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -736,8 +736,7 @@ static bool mctl_phy_init(struct dram_para *para)
> > 
> > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc);
> > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x45c);
> > 
> > -   if (IS_ENABLED(CONFIG_DRAM_ODT_EN))
> > -   mctl_phy_configure_odt(para);
> > +   mctl_phy_configure_odt(para);
> > 
> > clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 4, 7, 0xa);






Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)

2023-01-04 Thread Tony Dinh
Hello,

On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár  wrote:
>
> On Wednesday 04 January 2023 23:41:05 Chris Packham wrote:
> > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár,  wrote:
> >
> > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385
> > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which
> > > > > is not currently supported in u-boot (also cc this to Chris for
> > > > > commenting about Marvell DDR4 training driver).
> > > >
> > > > Yes, ddr4 training code is not in u-boot yet.
> > > >
> > > > A38x u-boot ddr driver is in this directory:
> > > >
> > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x
> > > >
> > > > And it is copied from the original marvell driver by stripping non-a38x
> > > > code and removal of the ddr4 code from the master branch:
> > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell
> > > >
> > > > So you can try to copy code again without stripping ddr4 parts
> > > > (run git log drivers/ddr/marvell/a38x in u-boot)
> > >
> > >
> > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460
> > >
> > > > And adjust u-boot board code for ddr4.
> > > >
> > > > I guess it could work but it would be needed to play with it.
> > >
> >
> > Last time I looked the MarvellEmbeddedProcessors stuff was a long way
> > behind what Marvell are releasing to customers. That was for the newer SoCs
> > so maybe the A385 stuff is current.
>
> About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and
> A3700-utils-marvell were up-to-date and same as the version distributed
> to the Marvell customers. I was cooperating with Marvell to release all
> patches from Marvell Extranet portal to github as opensource and also to
> incorporate github patches from community to their Extranet version.
> Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory with
> MarvellEmbeddedProcessors version. I do not think that Marvell released
> something super new in these repositories in last half of year, so I
> think that the code on MarvellEmbeddedProcessors (for those two
> repositories) is still up-to-date.

Thanks all for commenting. As Pali has suggested, I will try copying
the latest Marvell Github DDR drivers.

All the best,
Tony


> > >
> > > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This
> > > > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source
> > > > > for this board (provided by Thecus). My
> > > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this
> > > > >
> > > > > # Armada 38x uses version 1 image format
> > > > > VERSION 1
> > > > > # Boot Media configurations
> > > > > BOOT_FROM spi
> > > > > # Binary Header (bin_hdr) with DDR4 training code
> > > > > BINARY board/thecus/n2350/binary.0 005b 0068
> > > > >
> > > > > When I kwboot the u-boot.kwb image (using kwboot binary built with
> > > > > 2023.01-rc4), the header was transferred successfully, but then the
> > > > > BootROM jumped to SPI u-boot, instead of loading the u-boot payload
> > > > > from UART. Please see the log below.
> > > > > 
> > > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb
> > > > >
> > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty
> > > > > Patching image boot signature to UART
> > > > > Aligning image header to Xmodem block size
> > > > > Sending boot message. Please reboot the target.../
> > > > > Sending boot image header (97792 bytes)...
> > > > >   0 %
> > > [..]
> > > > >   9 %
> > > [..]
> > > > > 
> > > > >  82 %
> > > [..]
> > > > >  91 %
> > > [  ]
> > > > > Done
> > > > >
> > > > > BootROM - 1.73
> > > > > Booting from SPI flash
> > > >
> > > > This indicates reset of the board. BootROM started execution of the
> > > > image from the primary location.
> > > >
> > > > > 
> > > > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version:
> > > 2015_T1.0p18-tld-4
> > > > > 
> > > > >
> > > > > It seems kwboot patched the image, but the BOOT_FROM indicator was
> > > > > still recognized as from SPI. So the BootROM loaded the stock u-boot
> > > > > image from SPI and executed it. Since I am booting with bin_hdr, I'm
> > > > > not sure if there is something inside this blob that has forced this
> > > > > indicator to SPI.
> > > >
> > > > No, blob cannot force BootROM to switch boot location. This really
> > > > indicates crash of the blob or crash of the payload which results in the
> > > > board reset.
> > > >
> > > > > I'm attaching the u-boot.kwb image to this email, in 

Re: [PATCH 0/8] sunxi: Update H616 DRAM driver

2023-01-04 Thread Jernej Škrabec
Hi Andre!

Dne sreda, 04. januar 2023 ob 01:47:16 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:05 +0100
> Jernej Skrabec  wrote:
> 
> Hi Jernej,
> 
> > Current H616 DRAM driver is completely customized to Orange Pi Zero2
> > board, which is currently the only H616 board supported by U-Boot.
> > Needless to say, this is not ideal for adding new boards. With changes
> > in this series, all DDR3 boards are supported and all that is needed is
> > just vendor DRAM values extracted from Android image. New DRAM types
> > should also be easier to support, since a lot of constants used before
> > are not really DRAM type dependent.
> > 
> > Changes were verified by decompiling driver and generated values were
> > compared to previous, hard coded ones. This was done without dram_para
> > structures, so compiler was able to heavily optimize code and produce
> > constants.
> 
> so many thanks again for putting this together!
> I came to like (the idea of) this series very much lately, as this
> removes timing/delay values from the code, and easily allows putting the
> vendor provided values in the defconfig.
> I used that approach as well for the D1 driver, and am wondering if we
> should extend this to other SoCs, potentially unifying the Kconfig part?

While it would be nice, I'm not sure it's worth the effort and there is a 
chance that something might break during rework.

> 
> And you hinted at a v2, can you provide an estimate for this? If you
> send it still this week, I would like to put it into U-Boot's next
> branch, otherwise it goes straight into master, should the merge window
> open next week as planned.

I have changes for v2 in my github repo. I don't have any estimation, since I 
had some time off from programming lately and I'm just only catching up. 
Weekend at earliest, but no promises.

> 
> Btw., to verify the feasibility of drivers/ram/sunxi, I moved the H616
> driver into there, together with the Kconfig parts, I wonder what you
> think about this? An example of how this looks is in the D1 driver
> patches.

Looks good, but I don't know what are implications regarding interface. Is 
just code move or that implies that some ram framework must be used?

Best regards,
Jernej

> 
> Cheers,
> Andre
> 
> > Please take a look.
> > 
> > Best regards,
> > Jernej
> > 
> > Jernej Skrabec (8):
> >   sunxi: Fix write to H616 DRAM CR register
> >   sunxi: cosmetic: Fix H616 DRAM driver code style
> >   sunxi: parameterize H616 DRAM ODT values
> >   sunxi: Convert H616 DRAM options to single setting
> >   sunxi: Always configure ODT on H616 DRAM
> >   sunxi: Make bit delay function in H616 DRAM code void
> >   sunxi: Parameterize bit delay code in H616 DRAM driver
> >   sunxi: Parameterize H616 DRAM code some more
> >  
> >  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  18 +
> >  arch/arm/mach-sunxi/Kconfig   |  67 +--
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++---
> >  configs/orangepi_zero2_defconfig  |   8 +-
> >  4 files changed, 348 insertions(+), 190 deletions(-)






Re: Pull request for efi-2023-01-rc5-3

2023-01-04 Thread Tom Rini
On Wed, Jan 04, 2023 at 02:39:54PM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 582e3c9fb2337c2f49faa73ac86dde25f4d56901:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
> (2023-01-02 09:36:13 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2023-01-rc5-3
> 
> for you to fetch changes up to 60bba6e2052c281afe401247e10aebcb4c17049b:
> 
>   efi_loader: populate console handles in system table (2023-01-04
> 13:17:42 +0100)
> 
> Gitlab CI showed no issues:
> 
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/14580
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/4] Enable gigadevice and add new part #s

2023-01-04 Thread Vlim
Thanks, Michal,

Thanks for the feedback.

I do have some questions regarding the following comments,

Second. When I run this

for i in `ls configs/xilinx_*`; do NAME=`basename $i`; echo $NAME; make $NAME;
make savedefconfig; cp defconfig $i; done

I see that locations your added entries are not correct.

Third b4 am -g is showing that base is not upstream version.
Please use next branch as base.

Regarding the location of the entry, I believe you want me to add the entry in 
the alphabetical order?
This way it is the first line of this group of information.

CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_ISSI=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_WINBOND=y

However, I am not sure about the following requirement, please provide 
additional information.

Third b4 am -g is showing that base is not upstream version.
Please use next branch as base.

Also, for top posting, I am still not fully understood.
It seems like I should not include the previous email.
Let me try it here see if it is correct.

Regards,

Victor


Re: [PATCH 2/5] video console: refactoring and optimization

2023-01-04 Thread Simon Glass
Hi Dzmitry,

On Wed, 4 Jan 2023 at 04:17, Dzmitry Sankouski  wrote:
>
> Regarding code-size there's a gain with CONFIG_CONSOLE_ROTATION
> enabled, and penalty with disabled:
>
> New:
> CONFIG_VIDEO_CONSOLE=y
> CONFIG_CONSOLE_ROTATION=y
> dzmitry@debian:~/side/u-boot$ du --bytes drivers/video/console_simple.o
> 108208  drivers/video/console_simple.o
>
> CONFIG_VIDEO_CONSOLE=y
> # CONFIG_CONSOLE_ROTATION is not set
> dzmitry@debian:~/side/u-boot$ du --bytes drivers/video/console_simple.o
> 53848   drivers/video/console_simple.o
>
> Old:
> dzmitry@debian:~/side/u-boot$ du --bytes drivers/video/console_normal.o
> 44728   drivers/video/console_normal.o
> dzmitry@debian:~/side/u-boot$ du --bytes drivers/video/console_rotate.o
> 85424   drivers/video/console_rotate.o
>
> In theory, there should be a small performance penalty for the `if
> (direction)` statement -
> for every row, and for each pixel. For an 8x16 font, it'll be 144 if 
> statements.
>
> I'll comment on functions in the next patch versions.

To check this, use:

buildman -b  

to build each commit, then

buildman -b   -sS

You can add -B for function bloat and --step 0 to diff just the first
and last commits.


- Simon

>
> пт, 30 дек. 2022 г. в 01:41, Simon Glass :
> >
> > Hi Dzmitry,
> >
> > On Mon, 26 Dec 2022 at 13:50, Dzmitry Sankouski  
> > wrote:
> > >
> > > - get rid of code duplications in switch across bpp values
> > > - extract common pixel fill logic in two functions one per
> > > horizontal and vertical filling
> > > - rearrange statements in put_xy* methods in unified way
> > > - replace types - uint*_t to u*
> > >
> > > Signed-off-by: Dzmitry Sankouski 
> > > ---
> > >  drivers/video/console_simple.c | 508 -
> > >  1 file changed, 184 insertions(+), 324 deletions(-)
> >
> > This looks like a nice tidy up.
> >
> > Is there a code-size or performance penalty with this? E.g. with
> > CONFIG_CONSOLE_ROTATION disabled
> >
> > Please can you comment the functions property so we know what they do?
> >
> > Regards,
> > Simon


Re: [PATCH 3/3] bootm: Support boot measurement

2023-01-04 Thread Simon Glass
Hi Eddie,

On Tue, 3 Jan 2023 at 13:42, Eddie James  wrote:
>
> Add a configuration option to measure the boot through the bootm
> function.
>
> Signed-off-by: Eddie James 
> ---
>  boot/bootm.c| 53 +
>  cmd/bootm.c |  2 ++
>  common/Kconfig  |  6 ++
>  include/image.h |  1 +
>  4 files changed, 62 insertions(+)

Please add a test for this feature, e.g. in test/boot or test/bootm.c
or in test/py/tests/test_fit.py or similar.

>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index a4c0870c0f..7f64d79035 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -22,6 +22,9 @@
>  #include 
>  #include 
>  #include 
> +#if defined(CONFIG_MEASURED_BOOT)
> +#include 
> +#endif

Drop the #ifdef as you can always include headers

>  #if defined(CONFIG_CMD_USB)
>  #include 
>  #endif
> @@ -713,6 +716,56 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int 
> argc,
> if (!ret && (states & BOOTM_STATE_FINDOTHER))
> ret = bootm_find_other(cmdtp, flag, argc, argv);
>
> +#if defined(CONFIG_MEASURED_BOOT)
> +   if (!ret && (states & BOOTM_STATE_MEASURE)) {

Please avoid #ifdef

Are you using patman? If so, it will automatically warn you about this
sort of thing.

   if (!IS_ENABLED(CONFIG_MEASURED_BOOT) && ret && (states &
BOOTM_STATE_MEASURE)) {

> +   void *initrd_buf;
> +   void *image_buf;
> +   const char *s;
> +   u32 rd_len;
> +

Please put all this code in a separate function.

> +   ret = tcg2_measurement_init();
> +   if (ret)
> +   goto measure_err;
> +
> +   image_buf = map_sysmem(images->os.image_start,
> +  images->os.image_len);
> +   ret = tcg2_measure_data(8, images->os.image_len, image_buf,
> +   EV_COMPACT_HASH, strlen("linux") + 1,
> +   (u8 *)"linux");
> +   if (ret)
> +   goto unmap_image;
> +
> +   rd_len = images->rd_end - images->rd_start;
> +   initrd_buf = map_sysmem(images->rd_start, rd_len);
> +   ret = tcg2_measure_data(8, rd_len, initrd_buf, 
> EV_COMPACT_HASH,
> +   strlen("initrd") + 1, (u8 *)"initrd");
> +   if (ret)
> +   goto unmap_initrd;
> +
> +   ret = tcg2_measure_data(9, images->ft_len,
> +   (u8 *)images->ft_addr,
> +   EV_TABLE_OF_DEVICES, strlen("dts") + 
> 1,
> +   (u8 *)"dts");
> +   if (ret)
> +   goto unmap_initrd;
> +
> +   s = env_get("bootargs");
> +   if (!s)
> +   s = "";
> +   tcg2_measure_data(1, strlen(s) + 1, (u8 *)s,
> + EV_PLATFORM_CONFIG_FLAGS, strlen(s) + 1,
> + (u8 *)s);
> +
> +unmap_initrd:
> +   unmap_sysmem(initrd_buf);
> +unmap_image:
> +   unmap_sysmem(image_buf);
> +   tcg2_measurement_term();
> +measure_err:
> +   ret = 0;
> +   }
> +#endif
> +
> /* Load the OS */
> if (!ret && (states & BOOTM_STATE_LOADOS)) {
> iflag = bootm_disable_interrupts();
> diff --git a/cmd/bootm.c b/cmd/bootm.c
> index 37c2af96e0..0c4a713e02 100644
> --- a/cmd/bootm.c
> +++ b/cmd/bootm.c
> @@ -161,6 +161,8 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc, 
> char *const argv[])
> BOOTM_STATE_OS_GO;
> if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
> states |= BOOTM_STATE_RAMDISK;
> +   if (IS_ENABLED(CONFIG_MEASURED_BOOT))
> +   states |= BOOTM_STATE_MEASURE;
> if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
> states |= BOOTM_STATE_OS_CMDLINE;
> ret = do_bootm_states(cmdtp, flag, argc, argv, states, , 1);
> diff --git a/common/Kconfig b/common/Kconfig
> index 21434c5cf1..57ef68e4f3 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -799,6 +799,12 @@ config AVB_BUF_SIZE
>
>  endif # AVB_VERIFY
>
> +config MEASURED_BOOT
> +   bool "Measure the boot to TPM and event log"
> +   depends on HASH && TPM_V2
> +   help
> + This option enables measurement of the boot process.

Please add proper help. This will also come up as a warning if you use patman

> +
>  config SCP03
> bool "Build SCP03 - Secure Channel Protocol O3 - controls"
> depends on OPTEE || SANDBOX
> diff --git a/include/image.h b/include/image.h
> index 6f21dafba8..b00803eeac 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -406,6 +406,7 @@ struct bootm_headers {
>  #define BOOTM_STATE_OS_FAKE_GO 0x0200  /* 'Almost' run the OS */
>  #define BOOTM_STATE_OS_GO  

Re: [PATCH 1/2] clk: Allow clk_get_by_name() with NULL name

2023-01-04 Thread Simon Glass
Hi Samuel,

On Sun, 27 Nov 2022 at 22:54, Samuel Holland  wrote:
>
> This allows devm_clock_get(dev, NULL) to work and get the first clock,
> which is common in code ported from Linux.
>
> Signed-off-by: Samuel Holland 
> ---
>
>  drivers/clk/clk-uclass.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 2f9635524cf..bfacafb2eef 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -399,13 +399,14 @@ int clk_get_by_name(struct udevice *dev, const char 
> *name, struct clk *clk)
>
>  int clk_get_by_name_nodev(ofnode node, const char *name, struct clk *clk)
>  {
> -   int index;
> +   int index = 0;
>
> debug("%s(node=%p, name=%s, clk=%p)\n", __func__,
> ofnode_get_name(node), name, clk);
> clk->dev = NULL;
>
> -   index = ofnode_stringlist_search(node, "clock-names", name);
> +   if (name)
> +   index = ofnode_stringlist_search(node, "clock-names", name);
> if (index < 0) {
> debug("fdt_stringlist_search() failed: %d\n", index);
> return index;
> --
> 2.37.4
>

Same comments as for the reset patch.

Regards,
Simon


Re: [PATCH 2/2] reset: Allow reset_get_by_name() with NULL name

2023-01-04 Thread Simon Glass
Hi Samuel,

On Sun, 27 Nov 2022 at 22:54, Samuel Holland  wrote:
>
> This allows devm_reset_control_get(dev, NULL) to work and get the first
> reset control, which is common in code ported from Linux.
>
> Signed-off-by: Samuel Holland 
> ---
>
>  drivers/reset/reset-uclass.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
> index bcef46039c2..a26c623a77e 100644
> --- a/drivers/reset/reset-uclass.c
> +++ b/drivers/reset/reset-uclass.c
> @@ -147,13 +147,14 @@ int reset_get_bulk(struct udevice *dev, struct 
> reset_ctl_bulk *bulk)
>  int reset_get_by_name(struct udevice *dev, const char *name,
>  struct reset_ctl *reset_ctl)
>  {
> -   int index;
> +   int index = 0;
>
> debug("%s(dev=%p, name=%s, reset_ctl=%p)\n", __func__, dev, name,
>   reset_ctl);
> reset_ctl->dev = NULL;
>
> -   index = dev_read_stringlist_search(dev, "reset-names", name);
> +   if (name)
> +   index = dev_read_stringlist_search(dev, "reset-names", name);
> if (index < 0) {
> debug("fdt_stringlist_search() failed: %d\n", index);
> return index;

The above three lines should only be used when name is NULL.

> --
> 2.37.4
>

Please update the function comment in the header file and add a test
for this to test/dm/reset.c

Regards,
Simon


Re: [PATCH v8 09/13] rockchip: Use multiple-images for rk3399

2023-01-04 Thread Simon Glass
Hi Quentin,

On Mon, 2 Jan 2023 at 09:42, Quentin Schulz
 wrote:
>
> Hi Simon,
>
> On 12/22/22 00:07, Simon Glass wrote:
> > Enable multiple-images so we can generate more than one image. Also
> > add a comment for the end of the #if block.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v5)
> >
> > Changes in v5:
> > - Rename from 'Include binman script in 64-bit boards'
> > - Drop duplicate #include in rk3368-u-boot.dtsi
> > - Keep the name as fit for puma
> > - Drop redundant check for CONFIG_ROCKCHIP_SPI_IMAGE
> > - Drop imply of BINMAN in Kconfig (rely on ARCH_ROCKCHIP instead)
> >
> >   arch/arm/dts/rk3399-u-boot.dtsi | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/rk3399-u-boot.dtsi 
> > b/arch/arm/dts/rk3399-u-boot.dtsi
> > index 3c1a15fe51b..85a4f472d5d 100644
> > --- a/arch/arm/dts/rk3399-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> > @@ -62,6 +62,7 @@
> >
> >   #if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
> >{
> > + multiple-images;
> >   rom {
> >   filename = "u-boot.rom";
> >   size = <0x40>;
> > @@ -82,7 +83,7 @@
> >   };
> >   };
> >   };
> > -#endif
> > +#endif /* CONFIG_ROCKCHIP_SPI_IMAGE */
>
> && CONFIG_HAS_ROM
>
> On a different topic, I'm a bit confused by this u-boot.rom binary. is
> it not just for Chromebooks? We now have u-boot-rockchip-spi.bin for SPI
> images but they are different (same as u-boot-rockchip.bin, just
> formatted in a way it can be flashed on a SPI flash).

The .rom is for SPI flash, not just Chromebooks. Perhaps we should
unify the two of them?

Regards,
Simon


Re: [PATCH 0/3] tpm: Support boot measurements

2023-01-04 Thread Simon Glass
Hi Eddie,

On Wed, 4 Jan 2023 at 07:55, Eddie James  wrote:
>
>
> On 1/4/23 01:47, Ilias Apalodimas wrote:
> > Hi Eddie,
> > Thanks for the patch
> >
> > Looking at the patch there's a lot of code duplication with
> > lib/efi_loader/efi_tcg2.c.
> > Any reason why we aren't reusing that ?
>
>
> Hi,
>
> Well the EFI code can't be used directly without configuring to include
> the EFI subsystem and exporting a bunch of those functions in a header
> file somewhere, so I added the functions in the generic tpm librrary.
> Now it's a matter of doing the work to use the generic functions in the
> EFI system. I can do that in this series if necesssary, I just haven't
> gotten to it.

We cannot have EFI code in tpm-v2.h

The TPM layer should implement the feature, with the EFI layer calling
into it. This allows the TPM feature to be used by VBE and other
non-EFI systems.

Regards,
Simon


Re: [PATCH 00/17] Support android boot image v3/v4

2023-01-04 Thread Simon Glass
Hi Safae,

On Wed, 4 Jan 2023 at 02:02, safae ouajih  wrote:
>
> On 30/12/2022 02:48, Tom Rini wrote:
> > On Sat, 26 Nov 2022 17:59:14 +0100, Safae Ouajih wrote:
> >
> >> * This is based on Roman Stratiienko's work to support boot image header 
> >> version 3 and 4.
> >>
> >> * This supports the new boot image headers v3, v4 and bootconfig feature.
> >> https://source.android.com/docs/core/architecture/bootloader/boot-image-header
> >> https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig
> >>
> >> - Tested on Amlogic Khadas vim3l, a reference board for Android Open 
> >> Source Project
> >>https://www.khadas.com/vim3l
> >>
> >> [...]
> >
> > This series causes the test/py/tests/test_android/test_abootimg.py tests to
> > fail:
> > FAILED test/py/tests/test_android/test_abootimg.py::test_abootimg - 
> > ValueError: U-Boot exite...
> > and likely that test needs to be expanded for these new formats too.
> >
>
> Hello Tom,
>
> Thank you for reporting the failure. This will be fixed in a v2.

Please also update the test as requested.

Regards,
Simon


Re: [PATCH] rockchip: Fix the broken Video out for rk3288 boards

2023-01-04 Thread Simon Glass
On Mon, 2 Jan 2023 at 11:24, Jagan Teki  wrote:
>
> Video out on RK3288 boards has been broken since from few
> releases due to the adding of reset support on vop but
> missed enabling DM_RESET on associated boards.
>
> This patch fixes those RK3288 boards.
>
> Cc: Simon Glass 
> Cc: Lin Huang 
> Cc: Jernej Skrabec 
> Cc: Michael Trimarchi 
> Cc: Arnaud Patard (Rtp) 
> Fixes: <9749d2ea29e1> ("rockchip: video: vop: Add reset support")
> Reported-by: Manoj Sai 
> Signed-off-by: Jagan Teki 
> ---
>  configs/evb-rk3288_defconfig| 1 +
>  configs/firefly-rk3288_defconfig| 1 +
>  configs/miqi-rk3288_defconfig   | 1 +
>  configs/rock-pi-n8-rk3288_defconfig | 1 +
>  configs/tinker-rk3288_defconfig | 1 +
>  configs/tinker-s-rk3288_defconfig   | 1 +
>  configs/vyasa-rk3288_defconfig  | 1 +
>  7 files changed, 7 insertions(+)

Reviewed-by: Simon Glass 

This should get in for the release


Re: [PATCH] pylibfdt: Fix disable version normalization

2023-01-04 Thread Simon Glass
Hi Philippe,

On Wed, 4 Jan 2023 at 07:44, Philippe Schenker  wrote:
>
> From: Philippe Schenker 
>
> On Arch Linux based systems python setuptools does not contain
> "setuptools.extern" hence it is failing with the following
> error-message:
> "
> ModuleNotFoundError: No module named 'setuptools.extern'

Reviewed-by: Simon Glass 

What are you doing to create that error?

Regards,
Simon


> "
>
> According to a eschwartz `setuptools.extern` is not a public API and
> shall not be assumed to be present in the setuptools package. He
> mentions that the setuptools project anyway wants to drop this. [1]
>
> Use the correct solution introduced by python setuptools developers to
> disable normalization. [2]
>
> [1] https://bbs.archlinux.org/viewtopic.php?id=259608
> [2] https://github.com/pypa/setuptools/pull/2026
> Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning")
> Signed-off-by: Philippe Schenker 
>
> ---
>
>  scripts/dtc/pylibfdt/setup.py | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/dtc/pylibfdt/setup.py b/scripts/dtc/pylibfdt/setup.py
> index 9abdb57595ad..c07f65e6bcaf 100755
> --- a/scripts/dtc/pylibfdt/setup.py
> +++ b/scripts/dtc/pylibfdt/setup.py
> @@ -20,16 +20,12 @@ allows this script to be run stand-alone, e.g.:
>  ./pylibfdt/setup.py install [--prefix=...]
>  """
>
> -from setuptools import setup, Extension
> +from setuptools import setup, Extension, sic
>  from setuptools.command.build_py import build_py as _build_py
> -from setuptools.extern.packaging import version
>  import os
>  import re
>  import sys
>
> -# Disable version normalization
> -version.Version = version.LegacyVersion
> -
>  srcdir = os.path.dirname(__file__)
>
>  with open(os.path.join(srcdir, "../README"), "r") as fh:
> @@ -141,7 +137,7 @@ class build_py(_build_py):
>
>  setup(
>  name='libfdt',
> -version=version,
> +version=sic(version),
>  cmdclass = {'build_py' : build_py},
>  author='Simon Glass',
>  author_email='s...@chromium.org',
> --
> 2.39.0
>


Re: [PATCH v1 15/17] riscv: dts: jh7110: Add initial u-boot device tree

2023-01-04 Thread Sean Anderson

On 12/11/22 21:50, Yanhong Wang wrote:

Add initial u-boot device tree for the JH7110 RISC-V SoC.

Signed-off-by: Yanhong Wang 
---
  arch/riscv/dts/jh7110-u-boot.dtsi | 86 +++
  1 file changed, 86 insertions(+)
  create mode 100644 arch/riscv/dts/jh7110-u-boot.dtsi

diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi 
b/arch/riscv/dts/jh7110-u-boot.dtsi
new file mode 100644
index 00..243237e83a
--- /dev/null
+++ b/arch/riscv/dts/jh7110-u-boot.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ */
+
+#include 
+
+/ {
+   cpus: cpus {
+   u-boot,dm-spl;
+
+   cpu0: cpu@0 {
+   u-boot,dm-spl;
+   status = "okay";
+   cpu0_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+
+   cpu1: cpu@1 {
+   u-boot,dm-spl;
+   cpu1_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+
+   cpu2: cpu@2 {
+   u-boot,dm-spl;
+   cpu2_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+
+   cpu3: cpu@3 {
+   u-boot,dm-spl;
+   cpu3_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+
+   cpu4: cpu@4 {
+   u-boot,dm-spl;
+   cpu4_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };


Use the S76_0/U74_1/etc references you defined earlier.


+   };
+
+   soc {
+   u-boot,dm-spl;
+
+   clint: clint@200 {
+   u-boot,dm-spl;
+   };
+
+   dmc: dmc@1570 {
+   u-boot,dm-spl;
+   compatible = "starfive,jh7110-dmc";
+   reg = <0x0 0x1570 0x0 0x1>,
+   <0x0 0x1300 0x0 0x1>;
+   resets = < JH7110_SYSRST_DDR_AXI>,
+   < JH7110_SYSRST_DDR_OSC>,
+   < JH7110_SYSRST_DDR_APB>;
+   reset-names = "axi", "osc", "apb";
+   clocks = < JH7110_SYSCLK_PLL1_OUT>;
+   clock-names = "pll1";
+   clock-frequency = <2133>;
+   };


This should go in the SoC dtsi.


+   };
+};
+
+_rmii_refin {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};




[PATCH] arm: rockchip: Fix binman_init failure on RK3568

2023-01-04 Thread Jagan Teki
For some newer SoCs like RK3568, the Rockchip has not released
any DDR drivers yet so idbloader needs to create manually using
DDR binaries offered by rkbin. This indeed no requirement to
enable TPL in the U-Boot source code.

If we mark TPL disabled and mark BINMAN enabled by default then
there would be an issue of binman_init failure during board
relocation. This is true as binman failed to find the top-level
node like u-boot-tpl here.

Here is the boot issue observed in RK3566 board,

 U-Boot 2023.01-rc4-00057-gac2505d463-dirty (Jan 04 2023 - 23:44:18 +0530)

 Model: Radxa Compute Module 3(CM3) IO Board
 DRAM:  2 GiB
 binman_init failed:-2
 initcall sequence 7ffd2008 failed at call 00a18cac (err=-2)
 ### ERROR ### Please RESET the board ###

This might be fixed via binman node in rockchip-u-boot.dtsi however
disable binman for rk3568 for now as we are at the end of the release
cycle.

Fixes: 05713d570762 ("rockchip: generate u-boot-rockchip.bin with binman
for ARM64 boards")
Cc: Quentin Schulz 
Signed-off-by: Jagan Teki 
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cac4fa09fd..0e7a511c79 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1934,7 +1934,7 @@ config ARCH_STM32MP
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select BLK
-   select BINMAN if SPL_OPTEE || SPL
+   select BINMAN if SPL_OPTEE || (SPL && !ROCKCHIP_RK3568)
select DM
select DM_GPIO
select DM_I2C
-- 
2.25.1



Re: [PATCH v1 10/17] board: starfive: add StarFive VisionFive v2 board support

2023-01-04 Thread Sean Anderson

On 12/11/22 21:50, Yanhong Wang wrote:

Add board support for StarFive VisionFive v2.

Signed-off-by: Yanhong Wang 
---
  board/starfive/visionfive2/MAINTAINERS|   7 ++
  board/starfive/visionfive2/Makefile   |   7 ++
  board/starfive/visionfive2/spl.c  | 119 ++
  .../visionfive2/starfive_visionfive2.c|  39 ++
  include/configs/starfive-visionfive2.h|  18 +++
  5 files changed, 190 insertions(+)
  create mode 100644 board/starfive/visionfive2/MAINTAINERS
  create mode 100644 board/starfive/visionfive2/Makefile
  create mode 100644 board/starfive/visionfive2/spl.c
  create mode 100644 board/starfive/visionfive2/starfive_visionfive2.c
  create mode 100644 include/configs/starfive-visionfive2.h

diff --git a/board/starfive/visionfive2/MAINTAINERS 
b/board/starfive/visionfive2/MAINTAINERS
new file mode 100644
index 00..c5369086d8
--- /dev/null
+++ b/board/starfive/visionfive2/MAINTAINERS
@@ -0,0 +1,7 @@
+STARFIVE JH7110 VISIONFIVE2 BOARD
+M: startfive
+S: Maintained
+F: arch/riscv/include/asm/arch-jh7110/
+F: board/starfive/visionfive2/
+F: include/configs/starfive-visionfive2.h
+F: configs/starfive_visionfive2_defconfig
diff --git a/board/starfive/visionfive2/Makefile 
b/board/starfive/visionfive2/Makefile
new file mode 100644
index 00..66c854df39
--- /dev/null
+++ b/board/starfive/visionfive2/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2022 StarFive Technology Co., Ltd.
+#
+
+obj-y  := starfive_visionfive2.o
+obj-$(CONFIG_SPL_BUILD) += spl.o
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
new file mode 100644
index 00..473689eb71
--- /dev/null
+++ b/board/starfive/visionfive2/spl.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Author: Yanhong Wang
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define JH7110_CLK_CPU_ROOT_OFFSET 0x0U
+#define JH7110_CLK_CPU_ROOT_SHIFT  24
+#define JH7110_CLK_CPU_ROOT_MASK   GENMASK(29, 24)
+#define JH7110_CLK_BUS_ROOT_OFFSET 0x14U
+#define JH7110_CLK_BUS_ROOT_SHIFT  24
+#define JH7110_CLK_BUS_ROOT_MASK   GENMASK(29, 24)
+#define JH7110_CLK_PERH_ROOT_OFFSET0x10U
+#define JH7110_CLK_PERH_ROOT_SHIFT 24
+#define JH7110_CLK_PERH_ROOT_MASK  GENMASK(29, 24)
+#define JH7110_CLK_NOC_BUS_STG_AXI_OFFSET  0x180U
+#define JH7110_CLK_NOC_BUS_STG_AXI_SHIFT   31
+#define JH7110_CLK_NOC_BUS_STG_AXI_MASKBIT(31)
+#define JH7110_CLK_AON_APB_FUNC_OFFSET 0x4U
+#define JH7110_CLK_AON_APB_FUNC_SHIFT  24
+#define JH7110_CLK_AON_APB_FUNC_MASK   GENMASK(29, 24)
+#define JH7110_CLK_QSPI_REF_OFFSET 0x168U
+#define JH7110_CLK_QSPI_REF_SHIFT  24
+#define JH7110_CLK_QSPI_REF_MASK   GENMASK(29, 24)
+
+#define SET_DIV(type, val) \
+   clrsetbits_le32(JH7110_SYS_CRG + JH7110_CLK_##type##_OFFSET, \
+   JH7110_CLK_##type##_MASK, \
+   ((val) << JH7110_CLK_##type##_SHIFT) & JH7110_CLK_##type##_MASK)
+
+int spl_board_init_f(void)
+{
+   int ret;
+
+   ret = spl_soc_init();
+   if (ret) {
+   debug("JH7110 SPL init failed: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+u32 spl_boot_device(void)
+{
+   u32 mode;
+
+   mode = in_le32(JH7110_BOOT_MODE_SELECT_REG)
+   & JH7110_BOOT_MODE_SELECT_MASK;
+   switch (mode) {
+   case 0:
+   return BOOT_DEVICE_SPI;
+
+   case 1:
+   return BOOT_DEVICE_MMC2;
+
+   case 2:
+   return BOOT_DEVICE_MMC1;
+
+   case 3:
+   return BOOT_DEVICE_UART;
+
+   default:
+   debug("Unsupported boot device 0x%x.\n", mode);
+   return BOOT_DEVICE_NONE;
+   }
+}
+
+void board_init_f(ulong dummy)
+{
+   int ret;
+
+   ret = spl_early_init();
+   if (ret)
+   panic("spl_early_init() failed: %d\n", ret);
+
+   riscv_cpu_setup(NULL, NULL);
+   preloader_console_init();
+
+   /* select clk_pll0 by default */
+   SET_DIV(CPU_ROOT, 1);
+
+   /* select clk_pll2 by default */
+   SET_DIV(BUS_ROOT, 1);
+
+   /* select clk_pll2 by default */
+   SET_DIV(PERH_ROOT, 1);
+
+   SET_DIV(NOC_BUS_STG_AXI, 1);


Use assigned-clock-parents/assigned-clock-rates.

--Sean


+   clrsetbits_le32(JH7110_AON_CRG + JH7110_CLK_AON_APB_FUNC_OFFSET,
+   JH7110_CLK_AON_APB_FUNC_MASK,
+   BIT(JH7110_CLK_AON_APB_FUNC_SHIFT));
+
+   /* select clk_pll0 by default */
+   SET_DIV(QSPI_REF, 1);
+
+   ret = spl_board_init_f();
+   if (ret) {
+   debug("spl_board_init_f init failed: %d\n", ret);
+   return;
+   

Re: [PATCH v1 06/17] clk: starfive: Add StarFive JH7110 clock driver

2023-01-04 Thread Sean Anderson

On 12/11/22 21:50, Yanhong Wang wrote:

Add a DM clock driver for StarFive JH7110 SoC.





Signed-off-by: Yanhong Wang 
---
  drivers/clk/Kconfig   |   1 +
  drivers/clk/Makefile  |   1 +
  drivers/clk/starfive/Kconfig  |  15 +
  drivers/clk/starfive/Makefile |   4 +
  drivers/clk/starfive/clk-jh7110-pll.c | 362 ++
  drivers/clk/starfive/clk-jh7110.c | 651 ++
  drivers/clk/starfive/clk.h|  42 ++
  7 files changed, 1076 insertions(+)
  create mode 100644 drivers/clk/starfive/Kconfig
  create mode 100644 drivers/clk/starfive/Makefile
  create mode 100644 drivers/clk/starfive/clk-jh7110-pll.c
  create mode 100644 drivers/clk/starfive/clk-jh7110.c
  create mode 100644 drivers/clk/starfive/clk.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 09aa97ee8c..4d60c84aad 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -235,6 +235,7 @@ source "drivers/clk/owl/Kconfig"
  source "drivers/clk/renesas/Kconfig"
  source "drivers/clk/sunxi/Kconfig"
  source "drivers/clk/sifive/Kconfig"
+source "drivers/clk/starfive/Kconfig"
  source "drivers/clk/stm32/Kconfig"
  source "drivers/clk/tegra/Kconfig"
  source "drivers/clk/ti/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c274cda77c..66f5860356 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
  
  obj-y += analogbits/

  obj-y += imx/
+obj-$(CONFIG_CLK_JH7110) += starfive/
  obj-y += tegra/
  obj-y += ti/
  obj-$(CONFIG_$(SPL_TPL_)CLK_INTEL) += intel/
diff --git a/drivers/clk/starfive/Kconfig b/drivers/clk/starfive/Kconfig
new file mode 100644
index 00..e4bf2a5c5e
--- /dev/null
+++ b/drivers/clk/starfive/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+config SPL_CLK_JH7110
+   bool "SPL clock support for JH7110"
+   depends on STARFIVE_JH7110 && SPL
+   select SPL_CLK
+   select SPL_CLK_CCF
+   help
+ This enables SPL DM support for clock driver in JH7110.
+
+config CLK_JH7110
+   bool "StarFive JH7110 clock support"
+   depends on CLK && CLK_CCF && STARFIVE_JH7110
+   help
+ This enables support clock driver for StarFive JH7110 SoC platform.


Not a huge fan of CCF drivers, but whatever works for you.


diff --git a/drivers/clk/starfive/Makefile b/drivers/clk/starfive/Makefile
new file mode 100644
index 00..ec0d157094
--- /dev/null
+++ b/drivers/clk/starfive/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += clk-jh7110.o
+obj-y += clk-jh7110-pll.o
diff --git a/drivers/clk/starfive/clk-jh7110-pll.c 
b/drivers/clk/starfive/clk-jh7110-pll.c
new file mode 100644
index 00..8be9500b62
--- /dev/null
+++ b/drivers/clk/starfive/clk-jh7110-pll.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ *
+ * Author: Yanhong Wang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define UBOOT_DM_CLK_JH7110_PLLX "jh7110_clk_pllx"
+
+#define PLL0_DACPD_MASKBIT(24)
+#define PLL0_DSMPD_MASKBIT(25)
+#define PLL0_FBDIV_MASKGENMASK(11, 0)
+#define PLL0_FRAC_MASK GENMASK(23, 0)
+#define PLL0_PD_MASK   BIT(27)
+#define PLL0_POSTDIV1_MASK GENMASK(29, 28)
+#define PLL0_PREDIV_MASK   GENMASK(5, 0)
+#define PLL1_DACPD_MASKBIT(15)
+#define PLL1_DSMPD_MASKBIT(16)
+#define PLL1_FBDIV_MASKGENMASK(28, 17)
+#define PLL1_FRAC_MASK GENMASK(23, 0)
+#define PLL1_PD_MASK   BIT(27)
+#define PLL1_POSTDIV1_MASK GENMASK(29, 28)
+#define PLL1_PREDIV_MASK   GENMASK(5, 0)
+#define PLL2_DACPD_MASKBIT(15)
+#define PLL2_DSMPD_MASKBIT(16)
+#define PLL2_FBDIV_MASKGENMASK(28, 17)
+#define PLL2_FRAC_MASK GENMASK(23, 0)
+#define PLL2_PD_MASK   BIT(27)
+#define PLL2_POSTDIV1_MASK GENMASK(29, 28)
+#define PLL2_PREDIV_MASK   GENMASK(5, 0)
+
+#define PLL0_DACPD_OFFSET  0x18
+#define PLL0_DSMPD_OFFSET  0x18
+#define PLL0_FBDIV_OFFSET  0x1C
+#define PLL0_FRAC_OFFSET   0x20
+#define PLL0_PD_OFFSET 0x20
+#define PLL0_POSTDIV1_OFFSET   0x20
+#define PLL0_PREDIV_OFFSET 0x24
+#define PLL1_DACPD_OFFSET  0x24
+#define PLL1_DSMPD_OFFSET  0x24
+#define PLL1_FBDIV_OFFSET  0x24
+#define PLL1_FRAC_OFFSET   0x28
+#define PLL1_PD_OFFSET 0x28
+#define PLL1_POSTDIV1_OFFSET   0x28
+#define PLL1_PREDIV_OFFSET 0x2c
+#define PLL2_DACPD_OFFSET  0x2c
+#define PLL2_DSMPD_OFFSET  0x2c
+#define PLL2_FBDIV_OFFSET  0x2c
+#define PLL2_FRAC_OFFSET   0x30
+#define PLL2_PD_OFFSET 0x30
+#define PLL2_POSTDIV1_OFFSET   0x30
+#define PLL2_PREDIV_OFFSET 0x34
+
+#define PLL_PD_OFF 1
+#define PLL_PD_ON  0
+
+#define 

[PATCH 2/2] configs: verdin-imx8mm: Add bootaux command

2023-01-04 Thread Philippe Schenker
From: Philippe Schenker 

The i.MX 8M Mini SoC does incorporate an additional M-Core. To be able
to load it with a firmware, enable bootaux command as other Toradex
modules also have it enabled to be consistent.

Signed-off-by: Philippe Schenker 

---

 configs/verdin-imx8mm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
index 62f85883cb2d..5b5f7c051e54 100644
--- a/configs/verdin-imx8mm_defconfig
+++ b/configs/verdin-imx8mm_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_SPL=y
+CONFIG_IMX_BOOTAUX=y
 CONFIG_SYS_LOAD_ADDR=0x4820
 CONFIG_SYS_MEMTEST_START=0x4000
 CONFIG_SYS_MEMTEST_END=0x8000
-- 
2.39.0



[PATCH 1/2] imx: bootaux: Fix build warning when LTO is enabled

2023-01-04 Thread Philippe Schenker
From: Francesco Dolcini 

Fix conflicting declaration of hostmap[] variable. When building with
CONFIG_LTO=y we get the following warning:

  KSLCC   keep-syms-lto.o
  LTO u-boot
arch/arm/mach-imx/imx_bootaux.c:24:31: warning: type of ‘hostmap’ does not 
match original declaration [-Wlto-type-mismatch]
   24 | const __weak struct rproc_att hostmap[] = { };
  |   ^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: array types have different bounds
 1590 | const struct rproc_att hostmap[] = {
  |^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: ‘hostmap’ was previously declared 
here
  OBJCOPY u-boot.srec
  OBJCOPY u-boot-nodtb.bin

Just remove the __weak declaration and add an extern, in any case this
variable is supposed to be declared in the SOC file and there is no way
to have imx_bootaux build with this variable not declared.

In addition to that the weak variable definition is not correct,
get_host_mapping() will just reference non initialized data, if ever now
will have a build error instead of undefined behavior at runtime.

Signed-off-by: Francesco Dolcini 
Signed-off-by: Philippe Schenker 
---

 arch/arm/mach-imx/imx_bootaux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 8115bf40f1a9..6c00ef6007e7 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -21,7 +21,7 @@
 #define SRC_M4_REG_OFFSET  0
 #endif
 
-const __weak struct rproc_att hostmap[] = { };
+extern const struct rproc_att hostmap[];
 
 static const struct rproc_att *get_host_mapping(unsigned long auxcore)
 {
-- 
2.39.0



Re: [PATCH v1 01/11] clk: rockchip: rk3568: fix reset handler

2023-01-04 Thread Jagan Teki
On Tue, Feb 22, 2022 at 7:01 AM Peter Geis  wrote:
>
> The reset handler for rk3568 is missing its private data. This leads to
> an abort when a reset is triggered.
>
> Add the missing dev_set_priv to the rk3568 clk driver.
>
> Fixes: 4a262feba3a5 ("rockchip: rk3568: add clock driver")
>
> Signed-off-by: Peter Geis 
> ---

Reviewed-by: Jagan Teki 
Tested-by: Jagan Teki  # radxa-cm3


[PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY

2023-01-04 Thread Adam Ford
Due to the part shortage, the AR8031 PHY was replaced with a
Micrel KSZ9131. Enabling both config options keeps backward
compatibility with either platform, and both appear to be
auto-detected.

Signed-off-by: Adam Ford 

diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig
index 36787057a2..b4ea6c630a 100644
--- a/configs/rzg2_beacon_defconfig
+++ b/configs/rzg2_beacon_defconfig
@@ -68,6 +68,8 @@ CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_BITBANGMII=y
 CONFIG_BITBANGMII_MULTI=y
 CONFIG_PHY_ATHEROS=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_RENESAS_RAVB=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
-- 
2.34.1



Re: [PATCH v5 04/19] clk: at91: pmc: export clock setup to pmc

2023-01-04 Thread Sean Anderson

On 12/22/22 05:53, Sergiu Moga wrote:

From: Claudiu Beznea 

Clock setup was intended for setting clocks at boot time on SAMA7G5,
e.g. for root clocks like PLLs, that were used to feed IPs needed alive
in u-boot (e.g. Ethernet clock feed by a PLL). Export this functionality
to all at91 clocks as it may be necessary on other SoCs.

Signed-off-by: Claudiu Beznea 
Signed-off-by: Sergiu Moga 
---



v1 -> v2:
- Additional patch, this was not here in v1


v2 -> v5:
- No change



  drivers/clk/at91/pmc.c | 42 +
  drivers/clk/at91/pmc.h | 16 +
  drivers/clk/at91/sama7g5.c | 48 +-
  3 files changed, 64 insertions(+), 42 deletions(-)

diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 270892517a..87d2069d89 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -120,3 +120,45 @@ int at91_clk_mux_index_to_val(const u32 *table, u32 
num_parents, u32 index)
  
  	return table[index];

  }
+
+int at91_clk_setup(const struct pmc_clk_setup *setup, int size)
+{
+   struct clk *c, *parent;
+   int i, ret;
+
+   if (!size)
+   return 0;
+
+   if (!setup)
+   return -EINVAL;
+
+   for (i = 0; i < size; i++) {
+   ret = clk_get_by_id(setup[i].cid, );
+   if (ret)
+   return ret;
+
+   if (setup[i].pid) {
+   ret = clk_get_by_id(setup[i].pid, );
+   if (ret)
+   return ret;
+
+   ret = clk_set_parent(c, parent);
+   if (ret)
+   return ret;
+
+   if (setup[i].prate) {
+   ret = clk_set_rate(parent, setup[i].prate);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
+   if (setup[i].rate) {
+   ret = clk_set_rate(c, setup[i].rate);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
+   return 0;
+}
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 17793b8802..ff464522aa 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -77,6 +77,20 @@ struct clk_usbck_layout {
u32 usbdiv_mask;
  };
  
+/**

+ * Clock setup description
+ * @cid:   clock id corresponding to clock subsystem
+ * @pid:   parent clock id corresponding to clock subsystem
+ * @rate:  clock rate
+ * @prate: parent rate
+ */
+struct pmc_clk_setup {
+   unsigned int cid;
+   unsigned int pid;
+   unsigned long rate;
+   unsigned long prate;
+};
+
  extern const struct clk_programmable_layout at91rm9200_programmable_layout;
  extern const struct clk_programmable_layout at91sam9g45_programmable_layout;
  extern const struct clk_programmable_layout at91sam9x5_programmable_layout;
@@ -160,4 +174,6 @@ void pmc_write(void __iomem *base, unsigned int off, 
unsigned int val);
  void pmc_update_bits(void __iomem *base, unsigned int off, unsigned int mask,
unsigned int bits);
  
+int at91_clk_setup(const struct pmc_clk_setup *setup, int size);

+
  #endif
diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index d1ec3c82b5..8bd9c14156 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -1070,19 +1070,8 @@ static const struct {
},
  };
  
-/**

- * Clock setup description
- * @cid:   clock id corresponding to clock subsystem
- * @pid:   parent clock id corresponding to clock subsystem
- * @rate:  clock rate
- * @prate: parent rate
- */
-static const struct pmc_clk_setup {
-   unsigned int cid;
-   unsigned int pid;
-   unsigned long rate;
-   unsigned long prate;
-} sama7g5_clk_setup[] = {
+/* Clock setup description */
+static const struct pmc_clk_setup sama7g5_clk_setup[] = {
{
.cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_ETH_FRAC),
.rate = 62500,
@@ -1119,7 +1108,7 @@ static int sama7g5_clk_probe(struct udevice *dev)
unsigned int *muxallocs[SAMA7G5_MAX_MUX_ALLOCS];
const char *p[10];
unsigned int cm[10], m[10], *tmpclkmux, *tmpmux;
-   struct clk clk, *c, *parent;
+   struct clk clk, *c;
bool main_osc_bypass;
int ret, muxallocindex = 0, clkmuxallocindex = 0, i, j;
  
@@ -1353,34 +1342,9 @@ static int sama7g5_clk_probe(struct udevice *dev)

}
  
  	/* Setup clocks. */

-   for (i = 0; i < ARRAY_SIZE(sama7g5_clk_setup); i++) {
-   ret = clk_get_by_id(sama7g5_clk_setup[i].cid, );
-   if (ret)
-   goto fail;
-
-   if (sama7g5_clk_setup[i].pid) {
-   ret = clk_get_by_id(sama7g5_clk_setup[i].pid, );
-   if (ret)
-

Re: [PATCH v5 05/19] clk: at91: sam9x60: Add initial setup of UPLL and USBCK rates

2023-01-04 Thread Sean Anderson

On 12/22/22 05:53, Sergiu Moga wrote:

In order for some of the functionalities, such as the USB clocks,
to work properly we need some clocks to be properly initialised
at the very beginning of booting.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- Adapted according to the additional 04/19 PATCH, now making use of
`at91_clk_setup`



v2 -> v5:
- No change



  drivers/clk/at91/sam9x60.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
index 14c2ffcac1..e2f72446d5 100644
--- a/drivers/clk/at91/sam9x60.c
+++ b/drivers/clk/at91/sam9x60.c
@@ -378,6 +378,31 @@ static const struct {
{ .n = "dbgu_gclk",   .id = 47, },
  };
  
+/**

+ * Clock setup description
+ * @cid:   clock id corresponding to clock subsystem
+ * @pid:   parent clock id corresponding to clock subsystem
+ * @rate:  clock rate
+ * @prate: parent rate
+ */


It's not necessary to document structs where they are used.


+static const struct pmc_clk_setup sam9x60_clk_setup[] = {
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_FRAC),
+   .rate = 96000,
+   },
+
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_DIV),
+   .rate = 48000,
+   },
+
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_USBCK),
+   .pid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_DIV),
+   .rate = 4800,
+   },
+};
+
  #define prepare_mux_table(_allocs, _index, _dst, _src, _num, _label)  \
do {\
int _i; \
@@ -668,6 +693,11 @@ static int sam9x60_clk_probe(struct udevice *dev)
clk_dm(AT91_TO_CLK_ID(PMC_TYPE_GCK, sam9x60_gck[i].id), c);
}
  
+	/* Setup clocks. */

+   ret = at91_clk_setup(sam9x60_clk_setup, ARRAY_SIZE(sam9x60_clk_setup));
+   if (ret)
+   goto fail;
+
return 0;
  
  fail:


With that fixed:

Acked-by: Sean Anderson 


Re: [PATCH v5 03/19] clk: at91: sam9x60: Register the required clocks for USB

2023-01-04 Thread Sean Anderson

On 12/22/22 05:53, Sergiu Moga wrote:

Register into DM the clocks required to properly enable USB functionality
within the bootloader.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- No change


v2 -> v3:
- Remove the no longer required #if CONFIG_IS_ENABLED(AT91_SAM9X60_USB)


v3 -> v5:
- No change



  drivers/clk/at91/sam9x60.c | 33 +
  1 file changed, 33 insertions(+)

diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
index 6b5486c6c9..14c2ffcac1 100644
--- a/drivers/clk/at91/sam9x60.c
+++ b/drivers/clk/at91/sam9x60.c
@@ -76,6 +76,8 @@ enum pmc_clk_ids {
ID_QSPI = 18,
  
  	ID_MCK_PRES		= 19,

+   ID_USBCK= 20,
+   ID_UHPCK= 21,
  
  	ID_MAX,

  };
@@ -99,6 +101,7 @@ static const char *clk_names[] = {
[ID_PLL_A_DIV]  = "plla_divpmcck",
[ID_MCK_PRES]   = "mck_pres",
[ID_MCK_DIV]= "mck_div",
+   [ID_USBCK]  = "usbck",
  };
  
  /* Fractional PLL output range. */

@@ -171,6 +174,13 @@ static const struct clk_pcr_layout pcr_layout = {
.pid_mask = GENMASK(6, 0),
  };
  
+/* USB clock layout */

+static const struct clk_usbck_layout usbck_layout = {
+   .offset = 0x38,
+   .usbs_mask = GENMASK(1, 0),
+   .usbdiv_mask = GENMASK(11, 8),
+};
+
  /**
   * PLL clocks description
   * @n:clock name
@@ -266,6 +276,7 @@ static const struct {
u8 cid;
  } sam9x60_systemck[] = {
{ .n = "ddrck",   .p = "mck_div",  .id = 2, .cid = ID_DDR, 
},
+   { .n = "uhpck",   .p = "usbck",.id = 6, .cid = ID_UHPCK 
},
{ .n = "pck0",.p = "prog0",.id = 8, .cid = ID_PCK0, 
},
{ .n = "pck1",.p = "prog1",.id = 9, .cid = ID_PCK1, 
},
{ .n = "qspick",  .p = "mck_div",  .id = 19, .cid = ID_QSPI, },
@@ -543,6 +554,28 @@ static int sam9x60_clk_probe(struct udevice *dev)
}
clk_dm(AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_MCK_DIV), c);
  
+	/* Register usbck. */

+   p[0] = clk_names[ID_PLL_A_DIV];
+   p[1] = clk_names[ID_PLL_U_DIV];
+   p[2] = clk_names[ID_MAIN_XTAL];
+   m[0] = 0;
+   m[1] = 1;
+   m[2] = 2;
+   cm[0] = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_A_DIV);
+   cm[1] = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_DIV);
+   cm[2] = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_MAIN_XTAL);
+   prepare_mux_table(clkmuxallocs, clkmuxallocindex, tmpclkmux, cm,
+ 3, fail);
+   prepare_mux_table(muxallocs, muxallocindex, tmpmux, m, 3, fail);
+   c = sam9x60_clk_register_usb(base, clk_names[ID_USBCK], p, 3,
+_layout, tmpclkmux, tmpmux,
+ID_USBCK);
+   if (IS_ERR(c)) {
+   ret = PTR_ERR(c);
+   goto fail;
+   }
+   clk_dm(AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_USBCK), c);
+
/* Register programmable clocks. */
p[0] = clk_names[ID_MD_SLCK];
p[1] = clk_names[ID_TD_SLCK];


Acked-by: Sean Anderson 


Re: [PATCH v5 02/19] clk: at91: Add support for sam9x60 USB clock

2023-01-04 Thread Sean Anderson

On 12/22/22 05:53, Sergiu Moga wrote:

Implement sam9x60 USB clock driver. This clock has
three parents: PLLA, UPLL and MAINXTAL. The driver is
aware of the three possible parents with the help of the
two mux tables provied to the driver during the registration
of the clock.

Signed-off-by: Sergiu Moga 
---


v1 -> v4:
- No change


v4 -> v5:
- fix warning regarding below 0 check on unsigned variable


  drivers/clk/at91/Kconfig   |   7 ++
  drivers/clk/at91/Makefile  |   1 +
  drivers/clk/at91/clk-sam9x60-usb.c | 157 +
  drivers/clk/at91/pmc.h |  11 ++
  4 files changed, 176 insertions(+)
  create mode 100644 drivers/clk/at91/clk-sam9x60-usb.c

diff --git a/drivers/clk/at91/Kconfig b/drivers/clk/at91/Kconfig
index 4abc8026b4..4563892647 100644
--- a/drivers/clk/at91/Kconfig
+++ b/drivers/clk/at91/Kconfig
@@ -61,3 +61,10 @@ config AT91_SAM9X60_PLL
help
  This option is used to enable the AT91 SAM9X60's PLL clock
  driver.
+
+config AT91_SAM9X60_USB
+   bool "USB Clock support for SAM9X60 SoCs"
+   depends on CLK_AT91
+   help
+ This option is used to enable the AT91 SAM9X60's USB clock
+ driver.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 580b406d7b..e53dcb4ca7 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -9,6 +9,7 @@ obj-y += clk-peripheral.o
  obj-$(CONFIG_AT91_GENERIC_CLK)+= clk-generic.o
  obj-$(CONFIG_AT91_UTMI)   += clk-utmi.o
  obj-$(CONFIG_AT91_SAM9X60_PLL)+= clk-sam9x60-pll.o
+obj-$(CONFIG_AT91_SAM9X60_USB) += clk-sam9x60-usb.o
  obj-$(CONFIG_SAMA7G5) += sama7g5.o
  obj-$(CONFIG_SAM9X60) += sam9x60.o
  else
diff --git a/drivers/clk/at91/clk-sam9x60-usb.c 
b/drivers/clk/at91/clk-sam9x60-usb.c
new file mode 100644
index 00..798fa9eb3c
--- /dev/null
+++ b/drivers/clk/at91/clk-sam9x60-usb.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SAM9X60's USB Clock support.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga 
+ */
+
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define UBOOT_DM_CLK_AT91_SAM9X60_USB  "at91-sam9x60-usb-clk"
+
+struct sam9x60_usb {
+   const struct clk_usbck_layout   *layout;
+   void__iomem *base;
+   struct clk  clk;
+   const u32   *clk_mux_table;
+   const u32   *mux_table;
+   const char * const  *parent_names;
+   u32 num_parents;
+   u8  id;
+};
+
+#define to_sam9x60_usb(_clk)   container_of(_clk, struct sam9x60_usb, clk)
+#define USB_MAX_DIV15
+
+static int sam9x60_usb_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct sam9x60_usb *usb = to_sam9x60_usb(clk);
+   int index;
+   u32 val;
+
+   index = at91_clk_mux_val_to_index(usb->clk_mux_table, usb->num_parents,
+ parent->id);
+   if (index < 0)
+   return index;
+
+   index = at91_clk_mux_index_to_val(usb->mux_table, usb->num_parents,
+ index);
+   if (index < 0)
+   return index;
+
+   pmc_read(usb->base, usb->layout->offset, );
+   val &= ~usb->layout->usbs_mask;
+   val |= index << (ffs(usb->layout->usbs_mask - 1));


If you can't use FIELD_GET/PREP because the layout is dynamic, is
may be better to just store the shift/mask separately. Depends on
whether ffs is expensive on your arch, or whether it has its own
instruction.


+   pmc_write(usb->base, usb->layout->offset, val);
+
+   return 0;
+}
+
+static ulong sam9x60_usb_clk_get_rate(struct clk *clk)
+{
+   struct sam9x60_usb *usb = to_sam9x60_usb(clk);
+   ulong parent_rate = clk_get_parent_rate(clk);
+   u32 val, usbdiv;
+
+   if (!parent_rate)
+   return 0;
+
+   pmc_read(usb->base, usb->layout->offset, );
+   usbdiv = (val & usb->layout->usbdiv_mask) >>
+   (ffs(usb->layout->usbdiv_mask) - 1);
+   return parent_rate / (usbdiv + 1);
+}
+
+static ulong sam9x60_usb_clk_set_rate(struct clk *clk, ulong rate)
+{
+   struct sam9x60_usb *usb = to_sam9x60_usb(clk);
+   ulong parent_rate = clk_get_parent_rate(clk);
+   u32 usbdiv, val;
+
+   if (!parent_rate)
+   return 0;
+
+   usbdiv = DIV_ROUND_CLOSEST(parent_rate, rate);
+   if (usbdiv > USB_MAX_DIV + 1 || !usbdiv)
+   return 0;
+
+   pmc_read(usb->base, usb->layout->offset, );
+   val &= usb->layout->usbdiv_mask;
+   val |= (usbdiv - 1) << (ffs(usb->layout->usbdiv_mask) - 1);
+   pmc_write(usb->base, usb->layout->offset, val);
+
+   return parent_rate / usbdiv;
+}
+
+static 

Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)

2023-01-04 Thread Pali Rohár
On Wednesday 04 January 2023 23:41:05 Chris Packham wrote:
> On Wed, 4 Jan 2023, 8:52 PM Pali Rohár,  wrote:
> 
> > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote:
> > > Hello!
> > >
> > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385
> > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which
> > > > is not currently supported in u-boot (also cc this to Chris for
> > > > commenting about Marvell DDR4 training driver).
> > >
> > > Yes, ddr4 training code is not in u-boot yet.
> > >
> > > A38x u-boot ddr driver is in this directory:
> > >
> > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x
> > >
> > > And it is copied from the original marvell driver by stripping non-a38x
> > > code and removal of the ddr4 code from the master branch:
> > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell
> > >
> > > So you can try to copy code again without stripping ddr4 parts
> > > (run git log drivers/ddr/marvell/a38x in u-boot)
> >
> >
> > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460
> >
> > > And adjust u-boot board code for ddr4.
> > >
> > > I guess it could work but it would be needed to play with it.
> >
> 
> Last time I looked the MarvellEmbeddedProcessors stuff was a long way
> behind what Marvell are releasing to customers. That was for the newer SoCs
> so maybe the A385 stuff is current.

About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and
A3700-utils-marvell were up-to-date and same as the version distributed
to the Marvell customers. I was cooperating with Marvell to release all
patches from Marvell Extranet portal to github as opensource and also to
incorporate github patches from community to their Extranet version.
Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory with
MarvellEmbeddedProcessors version. I do not think that Marvell released
something super new in these repositories in last half of year, so I
think that the code on MarvellEmbeddedProcessors (for those two
repositories) is still up-to-date.

> >
> > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This
> > > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source
> > > > for this board (provided by Thecus). My
> > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this
> > > >
> > > > # Armada 38x uses version 1 image format
> > > > VERSION 1
> > > > # Boot Media configurations
> > > > BOOT_FROM spi
> > > > # Binary Header (bin_hdr) with DDR4 training code
> > > > BINARY board/thecus/n2350/binary.0 005b 0068
> > > >
> > > > When I kwboot the u-boot.kwb image (using kwboot binary built with
> > > > 2023.01-rc4), the header was transferred successfully, but then the
> > > > BootROM jumped to SPI u-boot, instead of loading the u-boot payload
> > > > from UART. Please see the log below.
> > > > 
> > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb
> > > >
> > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty
> > > > Patching image boot signature to UART
> > > > Aligning image header to Xmodem block size
> > > > Sending boot message. Please reboot the target.../
> > > > Sending boot image header (97792 bytes)...
> > > >   0 %
> > [..]
> > > >   9 %
> > [..]
> > > > 
> > > >  82 %
> > [..]
> > > >  91 %
> > [  ]
> > > > Done
> > > >
> > > > BootROM - 1.73
> > > > Booting from SPI flash
> > >
> > > This indicates reset of the board. BootROM started execution of the
> > > image from the primary location.
> > >
> > > > 
> > > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version:
> > 2015_T1.0p18-tld-4
> > > > 
> > > >
> > > > It seems kwboot patched the image, but the BOOT_FROM indicator was
> > > > still recognized as from SPI. So the BootROM loaded the stock u-boot
> > > > image from SPI and executed it. Since I am booting with bin_hdr, I'm
> > > > not sure if there is something inside this blob that has forced this
> > > > indicator to SPI.
> > >
> > > No, blob cannot force BootROM to switch boot location. This really
> > > indicates crash of the blob or crash of the payload which results in the
> > > board reset.
> > >
> > > > I'm attaching the u-boot.kwb image to this email, in case you are
> > > > interested in taking a look at the structure.
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > >
> >


Re: [PATCH] clk: sunxi: Add an A31/A23/A33 legacy PRCM MFD driver

2023-01-04 Thread Sean Anderson

On 11/18/22 23:47, Samuel Holland wrote:

When the CCU binding and driver for the PRCM were written, it seems the
intention was to convert the A31 and A23/A33 devicetrees to use them.
However, that never happened, so those SoCs still use the old binding,
with an MFD for the PRCM, and separate DT nodes for clocks and resets.

The specifier in the legacy clock/reset bindings is the register bit
offset, so the drivers are trivial. Only the outer PRCM node has a reg
property, so the clock/reset drivers use the parent device's MMIO base.

Signed-off-by: Samuel Holland 
---
I didn't reuse the sunxi gate/reset ops, because the driver is actually
smaller without them. I tested this driver on an A33 tablet.

  drivers/clk/sunxi/Kconfig  |  13 +++-
  drivers/clk/sunxi/Makefile |   1 +
  drivers/clk/sunxi/clk_sun6i_prcm.c | 104 +
  3 files changed, 116 insertions(+), 2 deletions(-)
  create mode 100644 drivers/clk/sunxi/clk_sun6i_prcm.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf11fad6eef..759ef410b66 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -39,11 +39,20 @@ config CLK_SUN6I_A31
  on Allwinner A31/A31s SoC.
  
  config CLK_SUN6I_A31_R

-   bool "Clock driver for Allwinner A31 generation PRCM"
+   bool "Clock driver for Allwinner A31 generation PRCM (CCU)"
default SUNXI_GEN_SUN6I
help
  This enables common clock driver support for the PRCM
- in Allwinner A31/A31s/A23/A33/A83T/H3/A64/H5 SoCs.
+ in Allwinner A31/A31s/A23/A33/A83T/H3/A64/H5 SoCs using
+ the CCU binding.
+
+config CLK_SUN6I_PRCM
+   bool "Clock driver for Allwinner A31 generation PRCM (legacy)"
+   default MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33
+   help
+ This enables common clock driver support for the PRCM
+ in Allwinner A31/A31s/A23/A33 SoCs using the legacy PRCM
+ MFD binding.
  
  config CLK_SUN8I_A23

bool "Clock driver for Allwinner A23/A33"
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 895da02ebea..3266409cc7a 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
  obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
  obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
  obj-$(CONFIG_CLK_SUN6I_A31_R) += clk_a31_r.o
+obj-$(CONFIG_CLK_SUN6I_PRCM) += clk_sun6i_prcm.o
  obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
  obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
  obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
diff --git a/drivers/clk/sunxi/clk_sun6i_prcm.c 
b/drivers/clk/sunxi/clk_sun6i_prcm.c
new file mode 100644
index 000..488b47e77a7
--- /dev/null
+++ b/drivers/clk/sunxi/clk_sun6i_prcm.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Samuel Holland 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sun6i_prcm_plat {
+   void *base;
+};
+
+static int sun6i_prcm_set_field(struct udevice *dev, uint reg,
+   u32 mask, bool set)
+{
+   struct sun6i_prcm_plat *plat = dev_get_plat(dev->parent);
+
+   clrsetbits_le32(plat->base + reg, mask, set ? mask : 0);
+
+   return 0;
+}
+
+static int sun6i_prcm_clk_enable(struct clk *clk)
+{
+   return sun6i_prcm_set_field(clk->dev, 0x28, BIT(clk->id), true);
+}
+
+static int sun6i_prcm_clk_disable(struct clk *clk)
+{
+   return sun6i_prcm_set_field(clk->dev, 0x28, BIT(clk->id), false);
+}
+
+static const struct clk_ops sun6i_prcm_clk_ops = {
+   .enable = sun6i_prcm_clk_enable,
+   .disable= sun6i_prcm_clk_disable,
+};
+
+static const struct udevice_id sun6i_prcm_clk_ids[] = {
+   { .compatible = "allwinner,sun6i-a31-apb0-gates-clk" },
+   { .compatible = "allwinner,sun8i-a23-apb0-gates-clk" },
+   { }
+};
+
+U_BOOT_DRIVER(sun6i_prcm_clk) = {
+   .name   = "sun6i_prcm_clk",
+   .id = UCLASS_CLK,
+   .of_match   = sun6i_prcm_clk_ids,
+   .ops= _prcm_clk_ops,
+};
+
+static int sun6i_prcm_reset_assert(struct reset_ctl *reset)
+{
+   return sun6i_prcm_set_field(reset->dev, 0xb0, BIT(reset->id), false);
+}
+
+static int sun6i_prcm_reset_deassert(struct reset_ctl *reset)
+{
+   return sun6i_prcm_set_field(reset->dev, 0xb0, BIT(reset->id), true);
+}
+
+static const struct reset_ops sun6i_prcm_reset_ops = {
+   .rst_assert = sun6i_prcm_reset_assert,
+   .rst_deassert   = sun6i_prcm_reset_deassert,
+};
+
+static const struct udevice_id sun6i_prcm_reset_ids[] = {
+   { .compatible = "allwinner,sun6i-a31-clock-reset" },
+   { }
+};
+
+U_BOOT_DRIVER(sun6i_prcm_reset) = {
+   .name   = "sun6i_prcm_reset",
+   .id = UCLASS_RESET,
+   .of_match   = sun6i_prcm_reset_ids,
+   .ops= _prcm_reset_ops,
+};
+
+static int sun6i_prcm_of_to_plat(struct udevice 

Re: [PATCH 3/3] clk: imx8mn: fix imx8mn_enet_phy_sels clocks list

2023-01-04 Thread Sean Anderson

On 12/19/22 06:31, Dario Binacchi wrote:

[backport from linux commit 2626cf67f20b28446dfc3a5b9493dd535cdb747b]

According to the "Clock Root" table of the reference manual (document
IMX8MNRM Rev 2, 07/2022):

  Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX])
 ...  ......
  ENET_PHY_REF_CLK_ROOT  0xAA80000 - 24M_REF_CLK
   001 - SYSTEM_PLL2_DIV20
   010 - SYSTEM_PLL2_DIV8
   011 - SYSTEM_PLL2_DIV5
   100 - SYSTEM_PLL2_DIV2
   101 - AUDIO_PLL1_CLK
   110 - VIDEO_PLL_CLK
   111 - AUDIO_PLL2_CLK
 ...  ......

while the imx8mn_enet_phy_sels list didn't contained audio_pll1_out for
source select bits 101b.

Signed-off-by: Dario Binacchi 

---

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

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index a2c7c63ef74d..692823e74b88 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -41,7 +41,7 @@ static const char *imx8mn_enet_timer_sels[] = {"clock-osc-24m", 
"sys_pll2_100m",
   "clk_ext3", "clk_ext4", 
"video_pll_out", };
  
  static const char *imx8mn_enet_phy_sels[] = {"clock-osc-24m", "sys_pll2_50m", "sys_pll2_125m", "sys_pll2_200m",

-"sys_pll2_500m", "video_pll_out", 
"audio_pll2_out", };
+"sys_pll2_500m", "audio_pll1_out", 
"video_pll_out", "audio_pll2_out", };
  #endif
  
  static const char *imx8mn_nand_usdhc_sels[] = {"clock-osc-24m", "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m",


Acked-by: Sean Anderson 


Re: [PATCH 2/3] clk: imx: rename video_pll1 to video_pll

2023-01-04 Thread Sean Anderson

On 12/19/22 06:31, Dario Binacchi wrote:

[backport from linux commit bedcf9d1dcf88ed38731f0ac9620e5a421e1e9d6]

Unlike audio_pll1 and audio_pll2, there is no video_pll2. Further, the
name used in the RM is video_pll. So, let's rename "video_pll1" to
"video_pll" to be consistent with the RM and avoid misunderstandings.

No functional changes intended.

Signed-off-by: Dario Binacchi 
---

  drivers/clk/imx/clk-imx8mn.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index 86fe30ae6662..a2c7c63ef74d 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -28,20 +28,20 @@ static const char *imx8mn_a53_sels[] = {"clock-osc-24m", 
"arm_pll_out", "sys_pll
"sys_pll1_800m", "sys_pll1_400m", 
"audio_pll1_out", "sys_pll3_out", };
  
  static const char *imx8mn_ahb_sels[] = {"clock-osc-24m", "sys_pll1_133m", "sys_pll1_800m", "sys_pll1_400m",

-   "sys_pll2_125m", "sys_pll3_out", 
"audio_pll1_out", "video_pll1_out", };
+   "sys_pll2_125m", "sys_pll3_out", 
"audio_pll1_out", "video_pll_out", };
  
  static const char *imx8mn_enet_axi_sels[] = {"clock-osc-24m", "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_250m",

-"sys_pll2_200m", "audio_pll1_out", 
"video_pll1_out", "sys_pll3_out", };
+"sys_pll2_200m", "audio_pll1_out", 
"video_pll_out", "sys_pll3_out", };
  
  #ifndef CONFIG_SPL_BUILD

  static const char *imx8mn_enet_ref_sels[] = {"clock-osc-24m", "sys_pll2_125m", 
"sys_pll2_50m", "sys_pll2_100m",
-"sys_pll1_160m", "audio_pll1_out", 
"video_pll1_out", "clk_ext4", };
+"sys_pll1_160m", "audio_pll1_out", 
"video_pll_out", "clk_ext4", };
  
  static const char *imx8mn_enet_timer_sels[] = {"clock-osc-24m", "sys_pll2_100m", "audio_pll1_out", "clk_ext1", "clk_ext2",

-  "clk_ext3", "clk_ext4", 
"video_pll1_out", };
+  "clk_ext3", "clk_ext4", 
"video_pll_out", };
  
  static const char *imx8mn_enet_phy_sels[] = {"clock-osc-24m", "sys_pll2_50m", "sys_pll2_125m", "sys_pll2_200m",

-"sys_pll2_500m", "video_pll1_out", 
"audio_pll2_out", };
+"sys_pll2_500m", "video_pll_out", 
"audio_pll2_out", };
  #endif
  
  static const char *imx8mn_nand_usdhc_sels[] = {"clock-osc-24m", "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m",

@@ -72,16 +72,16 @@ static const char *imx8mn_ecspi3_sels[] = {"osc_24m", 
"sys_pll2_200m", "sys_pll1
  #endif
  
  static const char *imx8mn_i2c1_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",

-"video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
+"video_pll_out", "audio_pll2_out", 
"sys_pll1_133m", };
  
  static const char *imx8mn_i2c2_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",

-"video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
+"video_pll_out", "audio_pll2_out", 
"sys_pll1_133m", };
  
  static const char *imx8mn_i2c3_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",

-"video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
+"video_pll_out", "audio_pll2_out", 
"sys_pll1_133m", };
  
  static const char *imx8mn_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",

-"video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
+"video_pll_out", "audio_pll2_out", 
"sys_pll1_133m", };
  
  static const char *imx8mn_wdog_sels[] = {"clock-osc-24m", "sys_pll1_133m", "sys_pll1_160m", "m7_alt_pll",

 "sys_pll2_125m", "sys_pll3_out", "sys_pll1_80m", 
"sys_pll2_166m", };
@@ -94,7 +94,7 @@ static const char *imx8mn_qspi_sels[] = {"clock-osc-24m", 
"sys_pll1_400m", "sys_
  
  static const char * const imx8mn_nand_sels[] = {"osc_24m", "sys_pll2_500m", "audio_pll1_out",

"sys_pll1_400m", "audio_pll2_out", 
"sys_pll3_out",
-   "sys_pll2_250m", 
"video_pll1_out", };
+   "sys_pll2_250m", 
"video_pll_out", };
  
  static const char * const imx8mn_usb_core_sels[] = {"clock-osc-24m", "sys_pll1_100m", "sys_pll1_40m",


Re: [PATCH 1/3] clk: imx8mn: rename vpu_pll to m7_alt_pll

2023-01-04 Thread Sean Anderson

On 12/19/22 06:31, Dario Binacchi wrote:

[backport from linux commit a429c60baefd95ab43a2ce7f25d5b2d7a2e431df]

The IMX8MN platform does not have any video processing unit (VPU), and
indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there
is no occurrence of its pll. From an analysis of the code and the RM
itself, I think vpu pll is used instead of m7 alternate pll, probably
for copy and paste of code taken from modules of similar architectures.

Signed-off-by: Dario Binacchi 
---

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

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index 35e0d935d390..86fe30ae6662 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -83,7 +83,7 @@ static const char *imx8mn_i2c3_sels[] = {"clock-osc-24m", 
"sys_pll1_160m", "sys_
  static const char *imx8mn_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", 
"sys_pll3_out", "audio_pll1_out",
 "video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
  
-static const char *imx8mn_wdog_sels[] = {"clock-osc-24m", "sys_pll1_133m", "sys_pll1_160m", "vpu_pll_out",

+static const char *imx8mn_wdog_sels[] = {"clock-osc-24m", "sys_pll1_133m", 
"sys_pll1_160m", "m7_alt_pll",
 "sys_pll2_125m", "sys_pll3_out", "sys_pll1_80m", 
"sys_pll2_166m", };
  
  static const char *imx8mn_usdhc3_sels[] = {"clock-osc-24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m",


Acked-by: Sean Anderson 


Re: [PATCH 2/2] reset: Allow reset_get_by_name() with NULL name

2023-01-04 Thread Sean Anderson

On 11/28/22 00:53, Samuel Holland wrote:

This allows devm_reset_control_get(dev, NULL) to work and get the first
reset control, which is common in code ported from Linux.

Signed-off-by: Samuel Holland 
---

  drivers/reset/reset-uclass.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index bcef46039c2..a26c623a77e 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -147,13 +147,14 @@ int reset_get_bulk(struct udevice *dev, struct 
reset_ctl_bulk *bulk)
  int reset_get_by_name(struct udevice *dev, const char *name,
 struct reset_ctl *reset_ctl)
  {
-   int index;
+   int index = 0;
  
  	debug("%s(dev=%p, name=%s, reset_ctl=%p)\n", __func__, dev, name,

  reset_ctl);
reset_ctl->dev = NULL;
  
-	index = dev_read_stringlist_search(dev, "reset-names", name);

+   if (name)
+   index = dev_read_stringlist_search(dev, "reset-names", name);
if (index < 0) {
debug("fdt_stringlist_search() failed: %d\n", index);
return index;


Reviewed-by: Sean Anderson 


Re: [PATCH 1/2] clk: Allow clk_get_by_name() with NULL name

2023-01-04 Thread Sean Anderson

On 11/28/22 00:53, Samuel Holland wrote:

This allows devm_clock_get(dev, NULL) to work and get the first clock,


nit: devm_clk_get


which is common in code ported from Linux.

Signed-off-by: Samuel Holland 
---

  drivers/clk/clk-uclass.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 2f9635524cf..bfacafb2eef 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -399,13 +399,14 @@ int clk_get_by_name(struct udevice *dev, const char 
*name, struct clk *clk)
  
  int clk_get_by_name_nodev(ofnode node, const char *name, struct clk *clk)

  {
-   int index;
+   int index = 0;
  
  	debug("%s(node=%p, name=%s, clk=%p)\n", __func__,

ofnode_get_name(node), name, clk);
clk->dev = NULL;
  
-	index = ofnode_stringlist_search(node, "clock-names", name);

+   if (name)
+   index = ofnode_stringlist_search(node, "clock-names", name);
if (index < 0) {
debug("fdt_stringlist_search() failed: %d\n", index);
return index;


Reviewed-by: Sean Anderson 


[PATCH v2] usb: gadget: fastboot: detach usb just before rebooting

2023-01-04 Thread Dario Binacchi
The patch fixes the following error when updating a BSH SMM S2 board:
3:72>Start Cmd:FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb ${filesize}
3:72>Okay (0.023s)
3:72>Start Cmd:FB: reboot
3:72>Fail Bulk(R):LIBUSB_ERROR_IO(0s)

The "fastboot reboot" command detaches the USB when it still needs to be
used. So let's detach the USB just before the reset.

CC: Mattijs Korpershoek 
Fixes: 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot commands")
Suggested-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

Changes in v2:
- Add 'Suggested-by' tag.

 drivers/usb/gadget/f_fastboot.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 07b1681c8a9a..0b3fae564d0a 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -419,11 +419,6 @@ static int fastboot_tx_write_str(const char *buffer)
return fastboot_tx_write(buffer, strlen(buffer));
 }
 
-static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
-{
-   do_reset(NULL, 0, 0, NULL);
-}
-
 static unsigned int rx_bytes_expected(struct usb_ep *ep)
 {
int rx_remain = fastboot_data_remaining();
@@ -495,6 +490,12 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct 
usb_request *req)
do_exit_on_complete(ep, req);
 }
 
+static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
+{
+   do_exit_on_complete(ep, req);
+   do_reset(NULL, 0, 0, NULL);
+}
+
 #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
 static void do_acmd_complete(struct usb_ep *ep, struct usb_request *req)
 {
@@ -544,7 +545,6 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
case FASTBOOT_COMMAND_REBOOT_RECOVERY:
fastboot_func->in_req->complete = compl_do_reset;
-   g_dnl_trigger_detach();
break;
 #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
case FASTBOOT_COMMAND_ACMD:
-- 
2.32.0



Re: riscv64 regression

2023-01-04 Thread Heinrich Schuchardt

On 1/4/23 16:49, Heinrich Schuchardt wrote:

On 1/4/23 16:34, Alex wrote:


Seeing a regression in functionality across multiple devices. I did a
bit of bisecting, here's the path:

Thu May 5 19:37:22 2022 -0400
working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0
no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0
unrecognized opcode `csrs sstatus,a5', extension `zicsr' required

Wed Oct 12 14:59:51 2022 +0200
broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr
issue)

Mon Dec 19 08:45:26 2022 -0500
broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0

Mon Jan 2 09:36:13 2023 -0500
broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0



Working boots our EFI loader fine.


Broke boots see similar Load Access faults multiple platforms (qemu,
unmatched, StarFive):


StarFive VisionFive 2:

SATP: 0x800fbe03
Calling ExitBootServices. So long, EFI!
clk u5_dw_i2c_clk_core already disabled
clk u5_dw_i2c_clk_apb already disabled
Unhandled exception: Load access fault
EPC: fe6dc496 RA: fe6dc488 TVAL: 
EPC: 3e98e496 RA: 3e98e488 reloc adjusted

SP: ff73b868 GP:  TP: 0001
T0: fbf28135 T1: 0008 T2: 
S0: 0021 S1:  A0: 0021
A1:  A2: 0001 A3: ff73b968
A4: 0001 A5: 01ff A6: 0020
A7: 000a S2: ff73b968 S3: ffc0020940c6
S4: fe713c80 S5: ff73be94 S6: ff73beb8
S7: ff73beb0 S8: ff73bea8 S9: ff73be98
S10: fe6fc288 S11: fe713c70 T3: 74757074
T4: ffe8 T5:  T6: fbf2810d

Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c)
UEFI image [0xfe6d:0xfe720fff] pc=0xc496
'/efi\boot\bootriscv64.efi'



My questions:

* Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot?
* Has anything else changed around memory management on riscv64 between
May 2022 and Oct 2022

-- Alex


Hello Alex,

I am not aware of a compiler problem.

The crash above occurs in bootriscv64.efi, not in U-Boot.

Analysis would require the code of that binary and instructions how to
recreate the problem on QEMU.

Best regards

Heinrich




Analysis of Haiku's efi.map file together with Alex showed that the
problem related to calling Haiku's vprintf() function after
ExitBootServices() which tries to invoke U-Boot's Simple Text Output
Protocol which is illegal after ExitBootServices().

Best regards

Heinrich



[PATCH v2] arm: dts: imx8mn-u-boot: fix DDR3 only support

2023-01-04 Thread Dario Binacchi
In case the CONFIG_IMX8M_LPDDR4 and CONFIG_IMX8M_DDR4 options are both
disabled (i. e. BSH boards), binmain fails because DDR4 bin files are
missing.

Fixes: 93c4c0e4dd1e75 ("arm: dts: imx8mn-u-boot: Create common 
imx8mn-u-boot.dtsi")
Signed-off-by: Dario Binacchi 
Reviewed-by: Michael Trimarchi 

---

Changes in v2:
- Fix typos in the commit message (DD3 --> DDR3, DD4 --> DDR4)

 arch/arm/dts/imx8mn-u-boot.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 95f45ad2522d..ec53390afb30 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -105,10 +105,11 @@
align-end = <4>;
};
 
+#if defined(CONFIG_IMX8M_LPDDR4) || defined(CONFIG_IMX8M_DDR4)
ddr-2d-imem-fw {
 #ifdef CONFIG_IMX8M_LPDDR4
filename = "lpddr4_pmu_train_2d_imem.bin";
-#elif CONFIG_IMX8M_DDR4
+#else
filename = "ddr4_imem_2d.bin";
 #endif
type = "blob-ext";
@@ -118,12 +119,13 @@
ddr-2d-dmem-fw {
 #ifdef CONFIG_IMX8M_LPDDR4
filename = "lpddr4_pmu_train_2d_dmem.bin";
-#elif CONFIG_IMX8M_DDR4
+#else
filename = "ddr4_dmem_2d.bin";
 #endif
type = "blob-ext";
align-end = <4>;
};
+#endif
};
 
spl {
-- 
2.32.0



Re: [PATCH] arm: dts: imx8mn-u-boot: fix DD3 only support

2023-01-04 Thread Michael Nazzareno Trimarchi
Hi

On Wed, Jan 4, 2023 at 5:17 PM Dario Binacchi
 wrote:
>
> In case the CONFIG_IMX8M_LPDDR4 and CONFIG_IMX8M_DDR4 options are both
> disabled (i. e. BSH boards), binmain fails because DD4 bin files are

DD4 DDR4

> missing.
>
> Fixes: 93c4c0e4dd1e75 ("arm: dts: imx8mn-u-boot: Create common 
> imx8mn-u-boot.dtsi")
> Signed-off-by: Dario Binacchi 
> ---
>
>  arch/arm/dts/imx8mn-u-boot.dtsi | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
> index 95f45ad2522d..ec53390afb30 100644
> --- a/arch/arm/dts/imx8mn-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-u-boot.dtsi
> @@ -105,10 +105,11 @@
> align-end = <4>;
> };
>
> +#if defined(CONFIG_IMX8M_LPDDR4) || defined(CONFIG_IMX8M_DDR4)
> ddr-2d-imem-fw {
>  #ifdef CONFIG_IMX8M_LPDDR4
> filename = "lpddr4_pmu_train_2d_imem.bin";
> -#elif CONFIG_IMX8M_DDR4
> +#else
> filename = "ddr4_imem_2d.bin";
>  #endif
> type = "blob-ext";
> @@ -118,12 +119,13 @@
> ddr-2d-dmem-fw {
>  #ifdef CONFIG_IMX8M_LPDDR4
> filename = "lpddr4_pmu_train_2d_dmem.bin";
> -#elif CONFIG_IMX8M_DDR4
> +#else
> filename = "ddr4_dmem_2d.bin";
>  #endif
> type = "blob-ext";
> align-end = <4>;
> };
> +#endif
> };
>
> spl {
> --
> 2.32.0
>

Reviewed-By: Michael Trimarchi 

>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


Re: [PATCH] usb: gadget: fastboot: detach usb just before rebooting

2023-01-04 Thread Marek Vasut

On 1/4/23 17:16, Dario Binacchi wrote:

The patch fixes the following error when updating a BSH SMM S2 board:
3:72>Start Cmd:FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb ${filesize}
3:72>Okay (0.023s)
3:72>Start Cmd:FB: reboot
3:72>Fail Bulk(R):LIBUSB_ERROR_IO(0s)

The "fastboot reboot" command detaches the USB when it still needs to be
used. So let's detach the USB just before the reset.

CC: Mattijs Korpershoek 
Fixes: 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot commands")
Signed-off-by: Dario Binacchi 
---

  drivers/usb/gadget/f_fastboot.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 07b1681c8a9a..0b3fae564d0a 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -419,11 +419,6 @@ static int fastboot_tx_write_str(const char *buffer)
return fastboot_tx_write(buffer, strlen(buffer));
  }
  
-static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)

-{
-   do_reset(NULL, 0, 0, NULL);
-}
-
  static unsigned int rx_bytes_expected(struct usb_ep *ep)
  {
int rx_remain = fastboot_data_remaining();
@@ -495,6 +490,12 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct 
usb_request *req)
do_exit_on_complete(ep, req);
  }
  
+static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)

+{
+   do_exit_on_complete(ep, req);
+   do_reset(NULL, 0, 0, NULL);
+}
+
  #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
  static void do_acmd_complete(struct usb_ep *ep, struct usb_request *req)
  {
@@ -544,7 +545,6 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
case FASTBOOT_COMMAND_REBOOT_RECOVERY:
fastboot_func->in_req->complete = compl_do_reset;
-   g_dnl_trigger_detach();
break;
  #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
case FASTBOOT_COMMAND_ACMD:


If Mattijs could have a look, that would be real nice.

If there is no activity in say a week or two, please let me know and 
I'll pick it up via USB tree.


[PATCH] configs: imx8mn_bsh_smm_s2: remove console from bootargs

2023-01-04 Thread Dario Binacchi
The Linux kernel device tree already specifies the device to be used for
boot console output with a stdout-path property under /chosen.

Fixes: 36b661dc919da ("Merge branch 'next'")
Signed-off-by: Dario Binacchi 
---

 include/configs/imx8mn_bsh_smm_s2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/imx8mn_bsh_smm_s2.h 
b/include/configs/imx8mn_bsh_smm_s2.h
index a2323bd6716f..2db670600f5a 100644
--- a/include/configs/imx8mn_bsh_smm_s2.h
+++ b/include/configs/imx8mn_bsh_smm_s2.h
@@ -14,7 +14,7 @@
 #include 
 
 #define NANDARGS \
-   "nandargs=setenv bootargs console=${console} " \
+   "nandargs=setenv bootargs " \
"${optargs} " \
"mtdparts=${mtdparts} " \
"root=${nandroot} " \
-- 
2.32.0



[PATCH] arm: dts: imx8mn-u-boot: fix DD3 only support

2023-01-04 Thread Dario Binacchi
In case the CONFIG_IMX8M_LPDDR4 and CONFIG_IMX8M_DDR4 options are both
disabled (i. e. BSH boards), binmain fails because DD4 bin files are
missing.

Fixes: 93c4c0e4dd1e75 ("arm: dts: imx8mn-u-boot: Create common 
imx8mn-u-boot.dtsi")
Signed-off-by: Dario Binacchi 
---

 arch/arm/dts/imx8mn-u-boot.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 95f45ad2522d..ec53390afb30 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -105,10 +105,11 @@
align-end = <4>;
};
 
+#if defined(CONFIG_IMX8M_LPDDR4) || defined(CONFIG_IMX8M_DDR4)
ddr-2d-imem-fw {
 #ifdef CONFIG_IMX8M_LPDDR4
filename = "lpddr4_pmu_train_2d_imem.bin";
-#elif CONFIG_IMX8M_DDR4
+#else
filename = "ddr4_imem_2d.bin";
 #endif
type = "blob-ext";
@@ -118,12 +119,13 @@
ddr-2d-dmem-fw {
 #ifdef CONFIG_IMX8M_LPDDR4
filename = "lpddr4_pmu_train_2d_dmem.bin";
-#elif CONFIG_IMX8M_DDR4
+#else
filename = "ddr4_dmem_2d.bin";
 #endif
type = "blob-ext";
align-end = <4>;
};
+#endif
};
 
spl {
-- 
2.32.0



[PATCH] usb: gadget: fastboot: detach usb just before rebooting

2023-01-04 Thread Dario Binacchi
The patch fixes the following error when updating a BSH SMM S2 board:
3:72>Start Cmd:FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb ${filesize}
3:72>Okay (0.023s)
3:72>Start Cmd:FB: reboot
3:72>Fail Bulk(R):LIBUSB_ERROR_IO(0s)

The "fastboot reboot" command detaches the USB when it still needs to be
used. So let's detach the USB just before the reset.

CC: Mattijs Korpershoek 
Fixes: 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot commands")
Signed-off-by: Dario Binacchi 
---

 drivers/usb/gadget/f_fastboot.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 07b1681c8a9a..0b3fae564d0a 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -419,11 +419,6 @@ static int fastboot_tx_write_str(const char *buffer)
return fastboot_tx_write(buffer, strlen(buffer));
 }
 
-static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
-{
-   do_reset(NULL, 0, 0, NULL);
-}
-
 static unsigned int rx_bytes_expected(struct usb_ep *ep)
 {
int rx_remain = fastboot_data_remaining();
@@ -495,6 +490,12 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct 
usb_request *req)
do_exit_on_complete(ep, req);
 }
 
+static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
+{
+   do_exit_on_complete(ep, req);
+   do_reset(NULL, 0, 0, NULL);
+}
+
 #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
 static void do_acmd_complete(struct usb_ep *ep, struct usb_request *req)
 {
@@ -544,7 +545,6 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
case FASTBOOT_COMMAND_REBOOT_RECOVERY:
fastboot_func->in_req->complete = compl_do_reset;
-   g_dnl_trigger_detach();
break;
 #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
case FASTBOOT_COMMAND_ACMD:
-- 
2.32.0



Re: [PATCH] arm: dts: rz-g2-beacon-u-boot: Fix QSPI Regression

2023-01-04 Thread Marek Vasut

On 1/4/23 16:53, Adam Ford wrote:

The QSPI is accessed via the RPC-IF, but the compatible flags
previously used a different name.  This compatibel name was changed
which broke the ability to access the QSPI.  Fix this by removing
the custom naming reference.

Fixes: 68083b897b57 ("renesas: Fix RPC-IF compatible values")
Signed-off-by: Adam Ford 


Reviewed-by: Marek Vasut 

Tom, please pick this directly for 2023.01 (or do you want a MR?)


[PATCH] arm: dts: rz-g2-beacon-u-boot: Fix QSPI Regression

2023-01-04 Thread Adam Ford
The QSPI is accessed via the RPC-IF, but the compatible flags
previously used a different name.  This compatibel name was changed
which broke the ability to access the QSPI.  Fix this by removing
the custom naming reference.

Fixes: 68083b897b57 ("renesas: Fix RPC-IF compatible values")
Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi 
b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
index 4d17854918..da1c3b0939 100644
--- a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
+++ b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
@@ -45,7 +45,6 @@
 };
 
  {
-   compatible = "renesas,rcar-gen3-rpc";
pinctrl-0 = <_pins>;
pinctrl-names = "default";
num-cs = <1>;
-- 
2.34.1



Re: riscv64 regression

2023-01-04 Thread Heinrich Schuchardt

On 1/4/23 16:34, Alex wrote:


Seeing a regression in functionality across multiple devices. I did a
bit of bisecting, here's the path:

Thu May 5 19:37:22 2022 -0400
working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0
no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0
unrecognized opcode `csrs sstatus,a5', extension `zicsr' required

Wed Oct 12 14:59:51 2022 +0200
broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr
issue)

Mon Dec 19 08:45:26 2022 -0500
broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0

Mon Jan 2 09:36:13 2023 -0500
broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0



Working boots our EFI loader fine.


Broke boots see similar Load Access faults multiple platforms (qemu,
unmatched, StarFive):


StarFive VisionFive 2:

SATP: 0x800fbe03
Calling ExitBootServices. So long, EFI!
clk u5_dw_i2c_clk_core already disabled
clk u5_dw_i2c_clk_apb already disabled
Unhandled exception: Load access fault
EPC: fe6dc496 RA: fe6dc488 TVAL: 
EPC: 3e98e496 RA: 3e98e488 reloc adjusted

SP: ff73b868 GP:  TP: 0001
T0: fbf28135 T1: 0008 T2: 
S0: 0021 S1:  A0: 0021
A1:  A2: 0001 A3: ff73b968
A4: 0001 A5: 01ff A6: 0020
A7: 000a S2: ff73b968 S3: ffc0020940c6
S4: fe713c80 S5: ff73be94 S6: ff73beb8
S7: ff73beb0 S8: ff73bea8 S9: ff73be98
S10: fe6fc288 S11: fe713c70 T3: 74757074
T4: ffe8 T5:  T6: fbf2810d

Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c)
UEFI image [0xfe6d:0xfe720fff] pc=0xc496
'/efi\boot\bootriscv64.efi'



My questions:

* Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot?
* Has anything else changed around memory management on riscv64 between
May 2022 and Oct 2022

-- Alex


Hello Alex,

I am not aware of a compiler problem.

The crash above occurs in bootriscv64.efi, not in U-Boot.

Analysis would require the code of that binary and instructions how to
recreate the problem on QEMU.

Best regards

Heinrich




Re: [PATCH 1/6] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes

2023-01-04 Thread Marek Vasut

On 1/4/23 11:11, eugen.hris...@microchip.com wrote:

On 1/4/23 11:38, Marek Vasut wrote:

On 1/4/23 08:30, eugen.hris...@microchip.com wrote:

On 1/3/23 01:12, Marek Vasut wrote:

On 12/23/22 13:33, Sergiu Moga wrote:

Add the OHCI and EHCI DT nodes for the sam9x60 boards.

Signed-off-by: Sergiu Moga 
---
    arch/arm/dts/at91-sam9x60_curiosity.dts | 21 +
    arch/arm/dts/sam9x60.dtsi   | 18 ++


Board and SoC DT changes should be in separate patches.


    arch/arm/dts/sam9x60ek.dts  | 21 +
    3 files changed, 60 insertions(+)



[...]


diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 17224ef771..e36a540f78 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
    #size-cells = <1>;
    ranges;

+ usb1: ohci@60 {


This should be usb@ instead of ohci@ , if you run "make dtbs_check" on
this DT in Linux (please do), you would likely get a warning , see Linux
Documentation/devicetree/bindings/usb/usb.yaml .



If in Linux we have ohci@ , then we need to have the same in U-boot.


You should update the Linux DT to usb@ too to avoid dtbs_check warnings.


We can accept the change to usb@ , if there is a pending patch in Linux.


I can make the same argument about Linux, since DTs are OS agnostic. My
comment is OS agnostic too and does not apply specifically to U-Boot or
Linux, it applies to DT.


Definitely you can comment in Linux , for sure.




U-boot is not the place to review the devicetree.


I strongly disagree with this statement.


There are a few decisions behind this statement.
First, the fact that we no longer take bindings into Uboot, and rely
solely on bindings in Linux. This means the bindings were reviewed and
validated in Linux.


Linux
1e5f532c27371 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
which added these ohci@ nodes has been accepted after Linux
14ec072a19ad7 ("dt-bindings: usb: Convert USB HCD generic binding to YAML")
was already in place.

Therefore, nobody ran the dtbs_check at that point, which is somewhat 
understandable, since the dtbs_check at that point was in very early stages.


This however shows the review process is not flawless and subsequent 
updates may be necessary.


One such update example is Linux:
979813d2ab705 ("ARM: dts: at91: use generic name for reset controller")
which does:
-   reset_controller: rstc@fe00 {
+   reset_controller: reset-controller@fe00 {
or another one:
6a743ea387e63 ("ARM: dts: at91: Use the generic "rtc" node name for the 
rtt IPs")

-   rtt: rtt@fe20 {
+   rtt: rtc@fe20 {
or another one:
4b6140b96dfe4 ("ARM: dts: at91: Use the generic "crypto" node name for 
the crypto IPs")

-   sha: sha@f002c000 {
+   sha: crypto@f002c000 {


Sure there are a few exceptions but not the usual rule.
Second, we rely on devicetree kernel.org mailing list to review all the
DTs and binding compliance in Linux.
This means that the DT has been validated and checked as ABI in Linux.


I think the ABI argument does not work, your own engineers would've 
caused multiple ABI breaks by now, see above.



Hence there is no place to question that in Uboot or any other project.


As you can see above, Linux kernel review process is not perfect and the 
code is constantly evolving rather than begin set in stone. I believe 
other projects and their reviewers are no worse than Linux kernel ones, 
and can provide valid review feedback too.



The DT must be the same and ABI across all software that uses the DT. If
this was validated and agreed upon in Linux, we can't question that here.
So if you disagree with this statement, it's your choice of course.


I strongly disagree.


What does it matter where the review feedback came from ?
What does matter is that you can improve the DT based on that feedback,
if the feedback is valid.


I agree with that, but if we want to improve things, we need to patch
things either in Linux first, or patch projects together.
The fact that you are against some patches while they have the same
identical node in Linux, is not a reason to not allow devicetree nodes
to be added to Uboot.
DT syncing with Linux is always a must, and that is part of what Sergiu
is doing with these patches.


See below.


The devicetree must be in sync with Linux.


I agree with this statement.

Please update the Linux DT too.


That is one approach but as I said, not a reason to reject a node that
is identical with Linux.


Ultimately, I am not the at91 maintainer, so I have no say in this.

I provided review feedback, that the DT checker would warn on the node 
name, and explained how to deal with it.


Whether the feedback is accepted and the DT is improved , or , the 
feedback is discarded and the DT checker keeps producing 

Re: [PATCH] pylibfdt: Fix disable version normalization

2023-01-04 Thread Tom Rini
On Wed, Jan 04, 2023 at 03:51:08PM +0100, Marek Vasut wrote:
> On 1/4/23 15:43, Philippe Schenker wrote:
> > From: Philippe Schenker 
> > 
> > On Arch Linux based systems python setuptools does not contain
> > "setuptools.extern" hence it is failing with the following
> > error-message:
> > "
> > ModuleNotFoundError: No module named 'setuptools.extern'
> > "
> > 
> > According to a eschwartz `setuptools.extern` is not a public API and
> > shall not be assumed to be present in the setuptools package. He
> > mentions that the setuptools project anyway wants to drop this. [1]
> > 
> > Use the correct solution introduced by python setuptools developers to
> > disable normalization. [2]
> > 
> > [1] https://bbs.archlinux.org/viewtopic.php?id=259608
> > [2] https://github.com/pypa/setuptools/pull/2026
> > Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning")
> > Signed-off-by: Philippe Schenker 
> 
> Nice, thank you.
> 
> Reviewed-by: Marek Vasut 
> 
> +CC Tom, this should go into this 2023.01 release.

Yes, thanks. I saw a similar change via a GitHub PR that was on my list
to properly resubmit.

-- 
Tom


signature.asc
Description: PGP signature


Re: riscv64 regression

2023-01-04 Thread Alexander von Gluck IV
January 4, 2023 9:35 AM, "Alex"  wrote:
> Seeing a regression in functionality across multiple devices. I did a bit of 
> bisecting, here's the
> path:

EEh.  Just added another data point.   The breakage for us happens on the gcc 
11.3.0 upgrade
of u-boot, not the 12.2.0 upgrade of u-boot.

Thu May 5 19:37:22 2022 -0400
  working:  03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0
  broke:  03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.3.0 (rebuild) 
  no build:  03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0  unrecognized 
opcode `csrs sstatus,a5', extension `zicsr' required

Wed Oct 12 14:59:51 2022 +0200
  broke:e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr 
issue)

Mon Dec 19 08:45:26 2022 -0500
  broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 11.1.0 (gets further)
  broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0 (errors out sooner)


Maybe the fact that the gcc 11.1.0 u-boot binary boots our EFI loader 
consistently is just a fluke.

I know adding some printf statements into our efi bootloader changes the 
behavior and solves
some memory access errors / Load Access Faults... so probably something with 
our memory layout?

 -- Alex


riscv64 regression

2023-01-04 Thread Alex
Seeing a regression in functionality across multiple devices. I did a bit of 
bisecting, here's the path:

Thu May 5 19:37:22 2022 -0400
working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0
no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized 
opcode `csrs sstatus,a5', extension `zicsr' required

Wed Oct 12 14:59:51 2022 +0200
broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue)

Mon Dec 19 08:45:26 2022 -0500
broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0

Mon Jan 2 09:36:13 2023 -0500
broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0
Working boots our EFI loader fine.
Broke boots see similar Load Access faults multiple platforms (qemu, unmatched, 
StarFive):
StarFive VisionFive 2:

SATP: 0x800fbe03
Calling ExitBootServices. So long, EFI!
clk u5_dw_i2c_clk_core already disabled
clk u5_dw_i2c_clk_apb already disabled
Unhandled exception: Load access fault
EPC: fe6dc496 RA: fe6dc488 TVAL: 
EPC: 3e98e496 RA: 3e98e488 reloc adjusted

SP: ff73b868 GP:  TP: 0001
T0: fbf28135 T1: 0008 T2: 
S0: 0021 S1:  A0: 0021
A1:  A2: 0001 A3: ff73b968
A4: 0001 A5: 01ff A6: 0020
A7: 000a S2: ff73b968 S3: ffc0020940c6
S4: fe713c80 S5: ff73be94 S6: ff73beb8
S7: ff73beb0 S8: ff73bea8 S9: ff73be98
S10: fe6fc288 S11: fe713c70 T3: 74757074
T4: ffe8 T5:  T6: fbf2810d

Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c)
UEFI image [0xfe6d:0xfe720fff] pc=0xc496 
'/efibootbootriscv64.efi'
My questions:

 * Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot?
 * Has anything else changed around memory management on riscv64 between May 
2022 and Oct 2022

 -- Alex


Re: [PATCH V4 00/12] AM68: Add support for AM68 Starter Kit

2023-01-04 Thread Sinthu Raja M
On Wed, Jan 4, 2023 at 3:14 PM Sinthu Raja
 wrote:
>
> From: Sinthu Raja 
>
> Hi All,
> This series of patch add initial support for AM68 starter kit.
> Design files can be referrred from https://www.ti.com/lit/zip/SPRR463
>
> Refer below link to J721S2/AM68 Technical Reference Manual for further 
> details:
> http://www.ti.com/lit/pdf/spruj28
>
> Link to kerenl patches:
> https://lore.kernel.org/linux-arm-kernel/20221115154832.19759-4-sinthu.r...@ti.com/T/#mff5847ea8cdef49337d224b7147f877bcc833aee
>
Tom,
Please let me know your comments on this series.
> Changes in V4:
> =
> Address review comments:
> - In align with the macro conditional statement which missed it in the 
> previous version
>
> Changes in V3:
> =
> Address review comments:
> - Rework on DTB selection API clarity about mini-U-Boot vs EVM and family 
> support as suggested.
>   * board: ti: j721s2: Add board_init and support for selecting DT based
> on EEPROM
>
> Changes in V2:
> =
> Address review comments:
> - Remove support for detecting multiple device trees using different DTB
> - Remove board specific API from K3 generic file 
> (arch/arm/mach-k3/j721s2_init.c) and moved to board specific file 
> (board/ti/j721s2/evm.c).
>   * arch: mach-k3: Update board specific API name to K3 generic API name
>   * board: ti: j721s2: Add board_init and support for selecting DT based
> on EEPROM
> - Move board_is_xxx within CONFIG_TI_I2C_BOARD_DETECT block to maintain the 
> "mini" U-Boot concept for this SoC.
>
> V1: 
> https://patchwork.ozlabs.org/project/uboot/cover/20221027104846.11820-1-sinthu.r...@ti.com/
> V2: 
> https://patchwork.ozlabs.org/project/uboot/cover/20221221135219.24702-1-sinthu.r...@ti.com/
> v3: 
> https://patchwork.ozlabs.org/project/uboot/cover/20221227121543.22306-1-sinthu.r...@ti.com/
>
> Sinthu Raja (12):
>   configs: j721s2_evm_r5: Enable support for building multiple dtbs into
> FIT
>   configs: j721s2_evm_a72: Enable support for building multiple dtbs
> into FIT
>   configs: j721s2_evm: Enable configs to store env in MMC FAT partition
>   board: ti: j721s2: Add support to update board_name for am68-sk
>   board: ti: j721s2: Enable support for reading EEPROM at next alternate
> address
>   board: ti: j721s2: Add support for detecting multiple device trees
>   arch: mach-k3: Update board specific API name to K3 generic API name
>   board: ti: j721s2: Add board_init and support for selecting DT based
> on EEPROM
>   arm: dts: Add initial support for AM68 Starter Kit System on Module
>   arm: dts: Add support for A72 specific AM68 Starter Kit Base Board
>   arm: dts: k3-am68-sk: Add r5 specific dt support
>   include: configs: Update env for selecting right dtb
>
>  arch/arm/dts/Makefile |   4 +-
>  .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 150 
>  arch/arm/dts/k3-am68-sk-base-board.dts| 353 ++
>  arch/arm/dts/k3-am68-sk-r5-base-board.dts | 194 ++
>  arch/arm/dts/k3-am68-sk-som.dtsi  | 127 +++
>  arch/arm/mach-k3/include/mach/sys_proto.h |   3 +
>  arch/arm/mach-k3/j721s2_init.c|  13 +-
>  board/ti/j721s2/evm.c | 118 +-
>  configs/j721s2_evm_a72_defconfig  |   4 +-
>  configs/j721s2_evm_r5_defconfig   |   4 +
>  include/configs/j721s2_evm.h  |   4 +
>  11 files changed, 956 insertions(+), 18 deletions(-)
>  create mode 100644 arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
>  create mode 100644 arch/arm/dts/k3-am68-sk-base-board.dts
>  create mode 100644 arch/arm/dts/k3-am68-sk-r5-base-board.dts
>  create mode 100644 arch/arm/dts/k3-am68-sk-som.dtsi
>
> --
> 2.36.1
>


-- 
With Regards
Sinthu Raja


Re: [PATCH 3/3] bootm: Support boot measurement

2023-01-04 Thread Eddie James



On 1/4/23 03:56, Etienne Carriere wrote:

Hello Eddie and all,

On Tue, 3 Jan 2023 at 21:42, Eddie James  wrote:

Add a configuration option to measure the boot through the bootm
function.

Signed-off-by: Eddie James 
---
  boot/bootm.c| 53 +
  cmd/bootm.c |  2 ++
  common/Kconfig  |  6 ++
  include/image.h |  1 +
  4 files changed, 62 insertions(+)

diff --git a/boot/bootm.c b/boot/bootm.c
index a4c0870c0f..7f64d79035 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,9 @@
  #include 
  #include 
  #include 
+#if defined(CONFIG_MEASURED_BOOT)
+#include 
+#endif
  #if defined(CONFIG_CMD_USB)
  #include 
  #endif
@@ -713,6 +716,56 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int 
argc,
 if (!ret && (states & BOOTM_STATE_FINDOTHER))
 ret = bootm_find_other(cmdtp, flag, argc, argv);

+#if defined(CONFIG_MEASURED_BOOT)
+   if (!ret && (states & BOOTM_STATE_MEASURE)) {
+   void *initrd_buf;
+   void *image_buf;
+   const char *s;
+   u32 rd_len;
+
+   ret = tcg2_measurement_init();
+   if (ret)
+   goto measure_err;
+
+   image_buf = map_sysmem(images->os.image_start,
+  images->os.image_len);
+   ret = tcg2_measure_data(8, images->os.image_len, image_buf,
+   EV_COMPACT_HASH, strlen("linux") + 1,
+   (u8 *)"linux");
+   if (ret)
+   goto unmap_image;
+
+   rd_len = images->rd_end - images->rd_start;
+   initrd_buf = map_sysmem(images->rd_start, rd_len);
+   ret = tcg2_measure_data(8, rd_len, initrd_buf, EV_COMPACT_HASH,
+   strlen("initrd") + 1, (u8 *)"initrd");
+   if (ret)
+   goto unmap_initrd;
+
+   ret = tcg2_measure_data(9, images->ft_len,
+   (u8 *)images->ft_addr,
+   EV_TABLE_OF_DEVICES, strlen("dts") + 1,
+   (u8 *)"dts");

This unconditionally measures DTB content but maybe there are
information that may differ at each boot as a random MAC address or an
ASLR seed.
Do you think something should condition measurement of the passed DTB
as proposed using a config switch in [1]?

[1] 
https://lore.kernel.org/all/20221207151110.529106-1-etienne.carri...@linaro.org/



That would make sense, I am happy to add that in v2. Should I use that 
config switch as-is or add a new one for the bootm measurement?


Thanks

Eddie




Regards,
Etienne


+   if (ret)
+   goto unmap_initrd;
+
+   s = env_get("bootargs");
+   if (!s)
+   s = "";
+   tcg2_measure_data(1, strlen(s) + 1, (u8 *)s,
+ EV_PLATFORM_CONFIG_FLAGS, strlen(s) + 1,
+ (u8 *)s);
+
+unmap_initrd:
+   unmap_sysmem(initrd_buf);
+unmap_image:
+   unmap_sysmem(image_buf);
+   tcg2_measurement_term();
+measure_err:
+   ret = 0;
+   }
+#endif
+
 /* Load the OS */
 if (!ret && (states & BOOTM_STATE_LOADOS)) {
 iflag = bootm_disable_interrupts();
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 37c2af96e0..0c4a713e02 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -161,6 +161,8 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 BOOTM_STATE_OS_GO;
 if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
 states |= BOOTM_STATE_RAMDISK;
+   if (IS_ENABLED(CONFIG_MEASURED_BOOT))
+   states |= BOOTM_STATE_MEASURE;
 if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
 states |= BOOTM_STATE_OS_CMDLINE;
 ret = do_bootm_states(cmdtp, flag, argc, argv, states, , 1);
diff --git a/common/Kconfig b/common/Kconfig
index 21434c5cf1..57ef68e4f3 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -799,6 +799,12 @@ config AVB_BUF_SIZE

  endif # AVB_VERIFY

+config MEASURED_BOOT
+   bool "Measure the boot to TPM and event log"
+   depends on HASH && TPM_V2
+   help
+ This option enables measurement of the boot process.
+
  config SCP03
 bool "Build SCP03 - Secure Channel Protocol O3 - controls"
 depends on OPTEE || SANDBOX
diff --git a/include/image.h b/include/image.h
index 6f21dafba8..b00803eeac 100644
--- a/include/image.h
+++ b/include/image.h
@@ -406,6 +406,7 @@ struct bootm_headers {
  #define BOOTM_STATE_OS_FAKE_GO 0x0200  /* 'Almost' run the OS */
  #define BOOTM_STATE_OS_GO  0x0400
  #define BOOTM_STATE_PRE_LOAD   0x0800
+#define BOOTM_STATE_MEASURE0x1000
 int state;

  #if 

Re: [PATCH 0/3] tpm: Support boot measurements

2023-01-04 Thread Eddie James



On 1/4/23 01:47, Ilias Apalodimas wrote:

Hi Eddie,
Thanks for the patch

Looking at the patch there's a lot of code duplication with
lib/efi_loader/efi_tcg2.c.
Any reason why we aren't reusing that ?



Hi,

Well the EFI code can't be used directly without configuring to include 
the EFI subsystem and exporting a bunch of those functions in a header 
file somewhere, so I added the functions in the generic tpm librrary. 
Now it's a matter of doing the work to use the generic functions in the 
EFI system. I can do that in this series if necesssary, I just haven't 
gotten to it.


Thanks,

Eddie




Regards
/Ilias

On Tue, 3 Jan 2023 at 22:42, Eddie James  wrote:

This series adds support for measuring the boot images more generically
than the existing EFI support. The series includes optional measurement
from the bootm command.
Eventually the EFI code could be refactored to use the generic functions.

Eddie James (3):
   tpm: Fix spelling for tpmu_ha union
   tpm: Support boot measurements
   bootm: Support boot measurement

  boot/bootm.c   |  53 
  cmd/bootm.c|   2 +
  common/Kconfig |   6 +
  include/efi_tcg2.h |  44 ---
  include/image.h|   1 +
  include/tpm-v2.h   | 139 -
  lib/tpm-v2.c   | 700 +
  7 files changed, 899 insertions(+), 46 deletions(-)

--
2.31.1



Re: [PATCH] pylibfdt: Fix disable version normalization

2023-01-04 Thread Marek Vasut

On 1/4/23 15:43, Philippe Schenker wrote:

From: Philippe Schenker 

On Arch Linux based systems python setuptools does not contain
"setuptools.extern" hence it is failing with the following
error-message:
"
ModuleNotFoundError: No module named 'setuptools.extern'
"

According to a eschwartz `setuptools.extern` is not a public API and
shall not be assumed to be present in the setuptools package. He
mentions that the setuptools project anyway wants to drop this. [1]

Use the correct solution introduced by python setuptools developers to
disable normalization. [2]

[1] https://bbs.archlinux.org/viewtopic.php?id=259608
[2] https://github.com/pypa/setuptools/pull/2026
Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning")
Signed-off-by: Philippe Schenker 


Nice, thank you.

Reviewed-by: Marek Vasut 

+CC Tom, this should go into this 2023.01 release.


[PATCH] pylibfdt: Fix disable version normalization

2023-01-04 Thread Philippe Schenker
From: Philippe Schenker 

On Arch Linux based systems python setuptools does not contain
"setuptools.extern" hence it is failing with the following
error-message:
"
ModuleNotFoundError: No module named 'setuptools.extern'
"

According to a eschwartz `setuptools.extern` is not a public API and
shall not be assumed to be present in the setuptools package. He
mentions that the setuptools project anyway wants to drop this. [1]

Use the correct solution introduced by python setuptools developers to
disable normalization. [2]

[1] https://bbs.archlinux.org/viewtopic.php?id=259608
[2] https://github.com/pypa/setuptools/pull/2026
Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning")
Signed-off-by: Philippe Schenker 

---

 scripts/dtc/pylibfdt/setup.py | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/scripts/dtc/pylibfdt/setup.py b/scripts/dtc/pylibfdt/setup.py
index 9abdb57595ad..c07f65e6bcaf 100755
--- a/scripts/dtc/pylibfdt/setup.py
+++ b/scripts/dtc/pylibfdt/setup.py
@@ -20,16 +20,12 @@ allows this script to be run stand-alone, e.g.:
 ./pylibfdt/setup.py install [--prefix=...]
 """
 
-from setuptools import setup, Extension
+from setuptools import setup, Extension, sic
 from setuptools.command.build_py import build_py as _build_py
-from setuptools.extern.packaging import version
 import os
 import re
 import sys
 
-# Disable version normalization
-version.Version = version.LegacyVersion
-
 srcdir = os.path.dirname(__file__)
 
 with open(os.path.join(srcdir, "../README"), "r") as fh:
@@ -141,7 +137,7 @@ class build_py(_build_py):
 
 setup(
 name='libfdt',
-version=version,
+version=sic(version),
 cmdclass = {'build_py' : build_py},
 author='Simon Glass',
 author_email='s...@chromium.org',
-- 
2.39.0



Re: [PATCH v3 3/3] usb: ohci-at91: Add USB PHY functionality

2023-01-04 Thread Marek Vasut

On 1/4/23 15:08, Sergiu Moga wrote:

Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 


Reviewed-by: Marek Vasut 

Thanks


Re: [PATCH v3 6/9] ARM: dts: sama7g5: Add USB and UTMI DT nodes

2023-01-04 Thread Marek Vasut

On 1/4/23 15:04, Sergiu Moga wrote:

Define the USB and UTMI DT nodes for the sama7g5 SoC's. Since these have
not yet been defined in upstream Linux, place them in the U-Boot specific
DT file.

Signed-off-by: Sergiu Moga 


Reviewed-by: Marek Vasut 


Re: [PATCH v3 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes

2023-01-04 Thread Marek Vasut

On 1/4/23 15:04, Sergiu Moga wrote:

Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.

Signed-off-by: Sergiu Moga 


Reviewed-by: Marek Vasut 


Re: [PATCH v2 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes

2023-01-04 Thread Marek Vasut

On 1/4/23 11:17, sergiu.m...@microchip.com wrote:

On 04.01.2023 11:56, Marek Vasut wrote:

On 1/4/23 08:24, eugen.hris...@microchip.com wrote:

On 1/3/23 18:00, Marek Vasut wrote:

On 1/3/23 16:56, sergiu.m...@microchip.com wrote:

On 03.01.2023 17:47, Marek Vasut wrote:

On 1/3/23 16:35, Sergiu Moga wrote:

Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.

Signed-off-by: Sergiu Moga 
---

v1 -> v2:
- use usb@

     arch/arm/dts/sam9x60.dtsi | 18 ++
     1 file changed, 18 insertions(+)

diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 17224ef771..4fcfb5c597 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
     #size-cells = <1>;
     ranges;

+ usb1: usb@60 {
+ compatible = "atmel,at91rm9200-ohci",
"usb-ohci";
+ reg = <0x0060 0x10>;
+ clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;


./scripts/checkpatch.pl on this patch indicates

WARNING: line length of 121 exceeds 100 columns
#93: FILE: arch/arm/dts/sam9x60.dtsi:75:
+   clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;

Please run checkpatch on all your patches.

Also, wait a few days before sending V2 , no need to send V2
immediately
while review of V1 is still ongoing.


It was my understanding that exceeding the character per line limit on
DT's is acceptable. All of our DT's are like this.


Not to my knowledge or per what is in other DTs.
Is that some exception here ?


DTs have not had restrictions on 80 chars per line. Have a look in Linux.

Also, as we have a requirement to keep the DT from Linux, we either have
to patch up Linux if there is a problem in the DT, or keep it in sync
with Linux.
We may have exceptions if there is a too big amount of work to be done
now to change things, to have differences in term of DT between Uboot
and Linux. But the general guideline is to keep the DT in sync with
Linux as it's ABI.


Linux checkpatch.pl --strict does complain about the line length for
sam9x60.dtsi , it was demoted from warning to check there.

Can you send a separate follow-up patch to U-Boot checkpatch.pl which
does the same , so we'd be in sync with Linux ?


I am sorry, I do not know at the moment where that change is supposed to
be made in checkpatch.pl.


Have a look at linux checkpatch.pl git log , it will be there already. 
It changes DT line length WARNING to CHECK .



So, right now, I would rather focus my time on
updating these patch series to be good enough and only afterwards I
would take a look at where exactly I should make the change for
checkpatch.pl as well, if that's fine. Thanks for the understanding.


Right, that's why I wrote separate follow up patch.


[PATCH v3 3/3] usb: ohci-at91: Add USB PHY functionality

2023-01-04 Thread Sergiu Moga
Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---



v1 -> v2:
- use *_bulk API's


v2 -> v3:
- use if (CONFIG_IS_ENABLED(...))


 drivers/usb/host/ohci-at91.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 92d0ab7184..171245ef6e 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -73,6 +73,7 @@ int usb_cpu_init_fail(void)
 #include 
 #include 
 #include "ohci.h"
+#include 
 
 #define AT91_MAX_USBH_PORTS3
 
@@ -90,15 +91,32 @@ struct at91_usbh_data {
 struct ohci_at91_priv {
ohci_t ohci;
struct clk_bulk clks;
+   struct phy_bulk phys;
 };
 
 static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
 {
+   if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+   int ret;
+
+   ret = generic_phy_power_on_bulk(_at91->phys);
+   if (ret)
+   return ret;
+   }
+
return clk_enable_bulk(_at91->clks);
 }
 
 static int at91_stop_clock(struct ohci_at91_priv *ohci_at91)
 {
+   if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+   int ret;
+
+   ret = generic_phy_power_off_bulk(_at91->phys);
+   if (ret)
+   return ret;
+   }
+
return clk_disable_bulk(_at91->clks);
 }
 
@@ -185,6 +203,16 @@ static int ohci_atmel_probe(struct udevice *dev)
if (ret)
goto fail;
 
+   if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+   ret = generic_phy_get_bulk(dev, _at91->phys);
+   if (ret)
+   goto fail;
+
+   ret = generic_phy_init_bulk(_at91->phys);
+   if (ret)
+   goto fail;
+   }
+
ret = at91_start_hc(dev);
if (ret)
goto fail;
-- 
2.34.1



[PATCH v3 2/3] usb: ohci-at91: Enable OHCI functionality and register into DM

2023-01-04 Thread Sergiu Moga
Register the OHCI driver into DM by properly initializing the required
clocks and pins required by the DT node of OHCI. In order for the VBUS
to stay enabled, a `child_pre_probe` method has been added to overcome
the DM core disabling it in `usb_scan_device`: when the generic
`device_probe` method is called, the pinctrl is processed once again,
undoing whatever changes have been made in our driver's probe method.

Furthermore, enable CONFIG_DM_GPIO whenever this driver and CONFIG_DM_USB
are selected.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- squashed 3/4 into this patch
- removed bool clocked
- use *_blk API's
- select DM_GPIO in Kconfig if DM_USB enabled
- use dev_read_u32_default



v2 -> v3:
- check value of dev_read_addr
- clk_disable in case of failure after at91_start_hc


 drivers/usb/host/Kconfig |   1 +
 drivers/usb/host/ohci-at91.c | 159 +++
 2 files changed, 160 insertions(+)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 6213b3c95f..bb1443a338 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -424,6 +424,7 @@ config USB_ATMEL
depends on ARCH_AT91
select SYS_USB_OHCI_CPU_INIT
select USB_OHCI_NEW
+   select DM_GPIO if DM_USB
 
 choice
prompt "Clock for OHCI"
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9b955c1bd6..92d0ab7184 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
  */
 
 #include 
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
 #include 
 
 int usb_cpu_init(void)
@@ -62,3 +65,159 @@ int usb_cpu_init_fail(void)
 {
return usb_cpu_stop();
 }
+
+#else
+
+#include 
+#include 
+#include 
+#include 
+#include "ohci.h"
+
+#define AT91_MAX_USBH_PORTS3
+
+#define at91_for_each_port(index, ports)   
\
+   for ((index) = 0;   
\
+(index) < min_t(u32, AT91_MAX_USBH_PORTS, (ports));
\
+(index)++)
+
+struct at91_usbh_data {
+   enum usb_init_type init_type;
+   struct gpio_desc vbus_pin[AT91_MAX_USBH_PORTS];
+   u32 ports;  /* number of ports on root hub 
*/
+};
+
+struct ohci_at91_priv {
+   ohci_t ohci;
+   struct clk_bulk clks;
+};
+
+static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
+{
+   return clk_enable_bulk(_at91->clks);
+}
+
+static int at91_stop_clock(struct ohci_at91_priv *ohci_at91)
+{
+   return clk_disable_bulk(_at91->clks);
+}
+
+static void ohci_at91_set_power(struct at91_usbh_data *pdata, int port,
+   bool enable)
+{
+   if (!dm_gpio_is_valid(>vbus_pin[port]))
+   return;
+
+   if (enable)
+   dm_gpio_set_dir_flags(>vbus_pin[port],
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+   else
+   dm_gpio_set_dir_flags(>vbus_pin[port], 0);
+}
+
+static int at91_start_hc(struct udevice *dev)
+{
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+   return at91_start_clock(ohci_at91);
+}
+
+static int at91_stop_hc(struct udevice *dev)
+{
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+   return at91_stop_clock(ohci_at91);
+}
+
+static int ohci_atmel_deregister(struct udevice *dev)
+{
+   struct at91_usbh_data *pdata = dev_get_plat(dev);
+   int ret, i;
+
+   ret = at91_stop_hc(dev);
+   if (ret)
+   return ret;
+
+   at91_for_each_port(i, pdata->ports)
+   ohci_at91_set_power(pdata, i, false);
+
+   return ohci_deregister(dev);
+}
+
+static int ohci_atmel_child_pre_probe(struct udevice *dev)
+{
+   struct udevice *ohci_controller = dev_get_parent(dev);
+   struct at91_usbh_data *pdata = dev_get_plat(ohci_controller);
+   int i;
+
+   at91_for_each_port(i, pdata->ports)
+   ohci_at91_set_power(pdata, i, true);
+
+   return 0;
+}
+
+static int ohci_atmel_probe(struct udevice *dev)
+{
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+   struct at91_usbh_data *pdata = dev_get_plat(dev);
+   struct ohci_regs *regs;
+   int ret;
+   u32 i;
+
+   regs = (struct ohci_regs *)dev_read_addr(dev);
+   if (IS_ERR(regs)) {
+   ret = PTR_ERR(regs);
+   goto fail;
+   }
+
+   pdata->ports = dev_read_u32_default(dev, "num-ports", 3);
+
+   at91_for_each_port(i, pdata->ports)
+   gpio_request_by_name(dev, "atmel,vbus-gpio", i,
+>vbus_pin[i], GPIOD_IS_OUT |
+GPIOD_IS_OUT_ACTIVE);
+
+   ret = clk_get_bulk(dev, _at91->clks);
+   if (ret)
+   goto fail;
+
+   ret = clk_enable_bulk(_at91->clks);
+   if (ret)
+   goto fail;
+
+   ret = at91_start_hc(dev);
+   if (ret)
+   

[PATCH v3 1/3] phy: at91: Add support for the USB 2.0 PHY's of SAMA7

2023-01-04 Thread Sergiu Moga
In order to have USB functionality, drivers for SAMA7's
USB 2.0 PHY's have been added. There is one driver
for UTMI clock's SFR and RESET required functionalities and
one for its three possible subclocks of the phy's themselves.
In order for this layout to properly work in conjunction with
CCF and DT, the former driver will also act as a clock provider
for the three phy's with the help of a custom hook into the
driver's of_xlate method.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---



v1 -> v2:
- Nothing


v2 -> v3:
- fix memory leak in the probe method


 drivers/phy/Kconfig  |  10 ++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-sama7-usb.c  |  90 +
 drivers/phy/phy-sama7-utmi-clk.c | 216 +++
 4 files changed, 317 insertions(+)
 create mode 100644 drivers/phy/phy-sama7-usb.c
 create mode 100644 drivers/phy/phy-sama7-utmi-clk.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index cf4d5908d7..9fbb956783 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -281,6 +281,16 @@ config PHY_XILINX_ZYNQMP
  Enable this to support ZynqMP High Speed Gigabit Transceiver
  that is part of ZynqMP SoC.
 
+config PHY_MICROCHIP_SAMA7_USB
+   tristate "Microchip SAMA7 USB 2.0 PHY"
+   depends on PHY && ARCH_AT91
+   help
+Enable this to support SAMA7 USB 2.0 PHY.
+
+The USB 2.0 PHY integrates high-speed, full-speed and low-speed
+termination and signal switching. With a single resistor, it
+requires minimal external components.
+
 source "drivers/phy/rockchip/Kconfig"
 source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/ti/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a3b9f3c5b1..9d50affd47 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
 obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
 obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
 obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
+obj-$(CONFIG_PHY_MICROCHIP_SAMA7_USB)  += phy-sama7-utmi-clk.o phy-sama7-usb.o
 obj-y += cadence/
 obj-y += ti/
 obj-y += qcom/
diff --git a/drivers/phy/phy-sama7-usb.c b/drivers/phy/phy-sama7-usb.c
new file mode 100644
index 00..200324d812
--- /dev/null
+++ b/drivers/phy/phy-sama7-usb.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip USB PHY's.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sama7_usb_phy {
+   struct clk *uclk;
+   struct regmap *sfr;
+   int port;
+};
+
+static int sama7_usb_phy_init(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+   int port = sama7_phy->port;
+
+   regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+  SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X,
+  SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X);
+
+   regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+  SAMA7_SFR_UTMI_RX_VBUS,
+  SAMA7_SFR_UTMI_RX_VBUS);
+
+   return 0;
+}
+
+static int sama7_phy_power_on(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+   clk_prepare_enable(sama7_phy->uclk);
+
+   return 0;
+}
+
+static int sama7_phy_power_off(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+   clk_disable_unprepare(sama7_phy->uclk);
+
+   return 0;
+}
+
+static int sama7_usb_phy_probe(struct udevice *dev)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(dev);
+
+   sama7_phy->uclk = devm_clk_get(dev, "utmi_clk");
+   if (IS_ERR(sama7_phy->uclk))
+   return PTR_ERR(sama7_phy->uclk);
+
+   sama7_phy->sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
+   if (IS_ERR(sama7_phy->sfr))
+   return PTR_ERR(sama7_phy->sfr);
+
+   return dev_read_u32(dev, "reg", _phy->port);
+}
+
+static const struct phy_ops sama7_usb_phy_ops = {
+   .init = sama7_usb_phy_init,
+   .power_on = sama7_phy_power_on,
+   .power_off = sama7_phy_power_off,
+};
+
+static const struct udevice_id sama7_usb_phy_of_match[] = {
+   { .compatible = "microchip,sama7g5-usb-phy", },
+   { },
+};
+
+U_BOOT_DRIVER(sama7_usb_phy_driver) = {
+   .name = "sama7-usb-phy",
+   .id = UCLASS_PHY,
+   .of_match = sama7_usb_phy_of_match,
+   .ops = _usb_phy_ops,
+   .probe = sama7_usb_phy_probe,
+   .priv_auto = sizeof(struct sama7_usb_phy),
+};
diff --git a/drivers/phy/phy-sama7-utmi-clk.c b/drivers/phy/phy-sama7-utmi-clk.c
new file mode 100644
index 00..2371b4341c
--- /dev/null
+++ b/drivers/phy/phy-sama7-utmi-clk.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for 

[PATCH v3 0/3] Register at91 OHCI into DM and add SAMA7 USB PHY's

2023-01-04 Thread Sergiu Moga
This patch series originates from a bigger patch series:
https://lists.denx.de/pipermail/u-boot/2022-December/502865.html

Register ohci-at91 driver into Driver Model. In order for the VBUS to
stay enabled, a `child_pre_probe` method has been added to overcome the
DM core disabling it in `usb_scan_device`: when the generic `device_probe`
method is called, the pinctrl is processed once again, undoing whatever
changes have been made in our driver's probe method.
In order to enable USB on SAMA7G5 the addition of the USB 2.0 PHY
drivers were required.

v1 -> v2:
- squashed previous 3/4 patch into 2/4 patch
- used *_bulk API's
- re-wrote at91_for_each_port
- use dev_read_u32_default for pdata->ports

v2 -> v3:
- corrected memory leak in the utmi phy driver probe method
- checked dev_read_addr return value
- add clk_disable in case of failure after at91_start_hc
- prefer using if (CONFIG_IS_ENABLED(...))
- add comment regarding why non-DM version must stay


Sergiu Moga (3):
  phy: at91: Add support for the USB 2.0 PHY's of SAMA7
  usb: ohci-at91: Enable OHCI functionality and register into DM
  usb: ohci-at91: Add USB PHY functionality

 drivers/phy/Kconfig  |  10 ++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-sama7-usb.c  |  90 +
 drivers/phy/phy-sama7-utmi-clk.c | 216 +++
 drivers/usb/host/Kconfig |   1 +
 drivers/usb/host/ohci-at91.c | 187 ++
 6 files changed, 505 insertions(+)
 create mode 100644 drivers/phy/phy-sama7-usb.c
 create mode 100644 drivers/phy/phy-sama7-utmi-clk.c

-- 
2.34.1



[PATCH v3 4/9] dt-bindings: reset: add sama7g5 definitions

2023-01-04 Thread Sergiu Moga
Upstream linux commit 5994f58977e0.

Add reset bindings for SAMA7G5. At the moment only USB PHYs are
included.

The three reset USB phy's have their ID's mapped from 4 to 6. There are
no USB phy's with ID's numbered from 0 to 3.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- nothing


v2 -> v3:
- added explanation in the commit message regarding missing id's 0-3


 include/dt-bindings/reset/sama7g5-reset.h | 10 ++
 1 file changed, 10 insertions(+)
 create mode 100644 include/dt-bindings/reset/sama7g5-reset.h

diff --git a/include/dt-bindings/reset/sama7g5-reset.h 
b/include/dt-bindings/reset/sama7g5-reset.h
new file mode 100644
index 00..2116f41d04
--- /dev/null
+++ b/include/dt-bindings/reset/sama7g5-reset.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RESET_SAMA7G5_H
+#define __DT_BINDINGS_RESET_SAMA7G5_H
+
+#define SAMA7G5_RESET_USB_PHY1 4
+#define SAMA7G5_RESET_USB_PHY2 5
+#define SAMA7G5_RESET_USB_PHY3 6
+
+#endif /* __DT_BINDINGS_RESET_SAMA7G5_H */
-- 
2.34.1



[PATCH v3 9/9] ARM: dts: sama5d27_wlsom1_ek: Add pinctrl nodes for USB DT nodes

2023-01-04 Thread Sergiu Moga
Add the pinctrl nodes required by the USB related DT nodes.

Signed-off-by: Sergiu Moga 
---

v1 -> v3:
- nothing


 arch/arm/dts/at91-sama5d27_wlsom1_ek.dts | 25 
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts 
b/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
index eec183d5de..6d4b35ea96 100644
--- a/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
@@ -143,7 +143,32 @@
pinmux = ;
bias-pull-up;
};
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
+
+   pinctrl_usba_vbus: usba_vbus {
+   pinmux = ;
+   bias-disable;
+   };
};
};
};
 };
+
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PA10 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 8/9] ARM: dts: sama5d2_icp: Add pinctrl nodes for USB related DT nodes

2023-01-04 Thread Sergiu Moga
Add the pinctrl subnodes required by the USB related DT nodes.

Signed-off-by: Sergiu Moga 
---

v1 -> v3:
- nothing

 arch/arm/dts/at91-sama5d2_icp.dts | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/at91-sama5d2_icp.dts 
b/arch/arm/dts/at91-sama5d2_icp.dts
index 2dffae9c5c..4f796c6c94 100644
--- a/arch/arm/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/dts/at91-sama5d2_icp.dts
@@ -154,7 +154,29 @@
 ;
bias-disable;
};
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
+
+   pinctrl_usba_vbus: usba_vbus {
+   pinmux = ;
+   bias-disable;
+   };
};
};
};
 };
+
+ {
+   num-ports = <3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   phy_type = "hsic";
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 7/9] ARM: dts: sama7g5ek: Add pinctrl, gpio and phy properties for USB

2023-01-04 Thread Sergiu Moga
Add the required pinctrl, gpio and phy properties required by the
USB DT nodes of the sama7g5ek boards. Since these have not yet been
defined in upstream Linux, place them in the U-Boot specific DT file.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- this patch was not here, previously split from 4/6 of v1


v2 -> v3:
- move the board specific properties in the U-Boot specific file and
mention it in the commit message


 arch/arm/dts/at91-sama7g5ek-u-boot.dtsi | 35 +
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi 
b/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
index f563071fe6..a54cfaccbf 100644
--- a/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
+++ b/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
@@ -10,6 +10,7 @@
  *
  */
 
+#include "sama7g5-pinfunc.h"
 #include 
 #include 
 
@@ -112,6 +113,11 @@
 
  {
u-boot,dm-pre-reloc;
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
 };
 
  {
@@ -133,3 +139,32 @@
  {
u-boot,dm-pre-reloc;
 };
+
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+  0
+   PIN_PC6 GPIO_ACTIVE_HIGH
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   phys = <_phy2>;
+   phy-names = "usb";
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy0 {
+   status = "okay";
+};
+
+_phy1 {
+   status = "okay";
+};
+
+_phy2 {
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 6/9] ARM: dts: sama7g5: Add USB and UTMI DT nodes

2023-01-04 Thread Sergiu Moga
Define the USB and UTMI DT nodes for the sama7g5 SoC's. Since these have
not yet been defined in upstream Linux, place them in the U-Boot specific
DT file.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- use usb@


v2 -> v3:
- place definitions in the U-Boot specific file and mention it in
the commit message


 arch/arm/dts/at91-sama7g5ek-u-boot.dtsi | 75 -
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi 
b/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
index d294ddb54a..f563071fe6 100644
--- a/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
+++ b/arch/arm/dts/at91-sama7g5ek-u-boot.dtsi
@@ -10,13 +10,87 @@
  *
  */
 
+#include 
+#include 
+
 / {
chosen {
u-boot,dm-pre-reloc;
};
 
+   utmi {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb_phy0: phy@0 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <0>;
+   clocks = <_clk USB_UTMI1>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb_phy1: phy@1 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <1>;
+   clocks = <_clk USB_UTMI2>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb_phy2: phy@2 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <2>;
+   clocks = <_clk USB_UTMI3>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+   };
+
+   utmi_clk: utmi-clk {
+   compatible = "microchip,sama7g5-utmi-clk";
+   sfr-phandle = <>;
+   #clock-cells = <1>;
+   clocks = < PMC_TYPE_CORE 27>;
+   clock-names = "utmi_clk";
+   resets = <_controller SAMA7G5_RESET_USB_PHY1>,
+<_controller SAMA7G5_RESET_USB_PHY2>,
+<_controller SAMA7G5_RESET_USB_PHY3>;
+   reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
+   };
+
soc {
u-boot,dm-pre-reloc;
+
+   usb2: usb@40 {
+   compatible = "microchip,sama7g5-ohci", "usb-ohci";
+   reg = <0x0040 0x10>;
+   interrupts = ;
+   clocks = < PMC_TYPE_PERIPHERAL 106>, <_clk 
USB_UTMI1>, <_clk>;
+   clock-names = "ohci_clk", "hclk", "uhpck";
+   status = "disabled";
+   };
+
+   usb3: usb@50 {
+   compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
+   reg = <0x0050 0x10>;
+   interrupts = ;
+   clocks = <_clk>, < PMC_TYPE_PERIPHERAL 106>;
+   clock-names = "usb_clk", "ehci_clk";
+   status = "disabled";
+   };
+
+   sfr: sfr@e1624000 {
+   compatible = "microchip,sama7g5-sfr", "syscon";
+   reg = <0xe1624000 0x4000>;
+   };
};
 };
 
@@ -59,4 +133,3 @@
  {
u-boot,dm-pre-reloc;
 };
-
-- 
2.34.1



[PATCH v3 3/9] ARM: dts: sam9x60ek: Add pinctrl and gpio properties for USB

2023-01-04 Thread Sergiu Moga
Add the required pinctrl and gpio properties required by the USB DT
nodes of the sam9x60ek boards.

Signed-off-by: Sergiu Moga 
---

v1 -> v2:
- this patch was not here, previously split from 1/6 of v1


v2 -> v3:
- nothing


 arch/arm/dts/sam9x60ek.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
index eb44868a3e..fb1e63c5b2 100644
--- a/arch/arm/dts/sam9x60ek.dts
+++ b/arch/arm/dts/sam9x60ek.dts
@@ -101,6 +101,13 @@
;
};
 
+   usb1 {
+   pinctrl_usb_default: usb_default {
+   atmel,pins = ;
+   };
+   };
+
};
};
};
@@ -110,3 +117,17 @@
phy-mode = "rmii";
status = "okay";
 };
+
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   15 GPIO_ACTIVE_HIGH
+   16 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 5/9] dt-bindings: clk: at91: Define additional UTMI related clocks

2023-01-04 Thread Sergiu Moga
Add definitions for an additional main UTMI clock as well as its
respective subclocks.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- nothing


v2 -> v3:
- added USB_ prefix


 include/dt-bindings/clk/at91.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/dt-bindings/clk/at91.h b/include/dt-bindings/clk/at91.h
index e30756b280..a178b94157 100644
--- a/include/dt-bindings/clk/at91.h
+++ b/include/dt-bindings/clk/at91.h
@@ -18,5 +18,10 @@
 #define PMC_TYPE_PERIPHERAL3
 #define PMC_TYPE_GCK   4
 #define PMC_TYPE_SLOW  5
+#define USB_UTMI   6
+
+#define USB_UTMI1  0
+#define USB_UTMI2  1
+#define USB_UTMI3  2
 
 #endif
-- 
2.34.1



[PATCH v3 2/9] ARM: dts: sam9x60_curiosity: Add pinctrl and gpio properties for USB

2023-01-04 Thread Sergiu Moga
Add the required pinctrl and gpio properties needed by the USB DT nodes
of the sam9x60_curiosity boards.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- this patch was not here, previously split from 1/6 of v1

v2 -> v3:
- nothing


 arch/arm/dts/at91-sam9x60_curiosity.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts 
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index 7c5b6ae2b8..d6ae3d648d 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -49,6 +49,13 @@
atmel,pins =
;
};
+
+   usb1 {
+   pinctrl_usb_default: 
usb_default {
+   atmel,pins = ;
+   };
+   };
};
};
};
@@ -89,3 +96,17 @@
phy-mode = "rmii";
status = "okay";
 };
+
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   15 GPIO_ACTIVE_HIGH
+   18 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 0/9] Add DT USB definitions for SAM9X60, SAMA5D2 and SAMA7

2023-01-04 Thread Sergiu Moga
This patch series originates from the bigger patch series:
https://lists.denx.de/pipermail/u-boot/2022-December/502865.html

Add the basic DT USB definitions for SAM9X60, SAMA5D2 and SAMA7. The
required pinctrl definitions have been added as well as additional
definitions for the UTMI related clocks and their relationship with the
Reset driver.

v1 -> v2:
- split patches for SoC/Board separately
- use usb@


v2 -> v3:
- update commit message regarding the SAMA7G5_RESET_USB_PHY id's
- added USB_ prefix to UTMI macro-definitions
- move sama7g5's USB DT definitions to U-Boot specific file


Sergiu Moga (9):
  ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
  ARM: dts: sam9x60_curiosity: Add pinctrl and gpio properties for USB
  ARM: dts: sam9x60ek: Add pinctrl and gpio properties for USB
  dt-bindings: reset: add sama7g5 definitions
  dt-bindings: clk: at91: Define additional UTMI related clocks
  ARM: dts: sama7g5: Add USB and UTMI DT nodes
  ARM: dts: sama7g5ek: Add pinctrl, gpio and phy properties for USB
  ARM: dts: sama5d2_icp: Add pinctrl nodes for USB related DT nodes
  ARM: dts: sama5d27_wlsom1_ek: Add pinctrl nodes for USB DT nodes

 arch/arm/dts/at91-sam9x60_curiosity.dts   |  21 +
 arch/arm/dts/at91-sama5d27_wlsom1_ek.dts  |  25 +
 arch/arm/dts/at91-sama5d2_icp.dts |  22 +
 arch/arm/dts/at91-sama7g5ek-u-boot.dtsi   | 108 ++
 arch/arm/dts/sam9x60.dtsi |  18 
 arch/arm/dts/sam9x60ek.dts|  21 +
 include/dt-bindings/clk/at91.h|   5 +
 include/dt-bindings/reset/sama7g5-reset.h |  10 ++
 8 files changed, 230 insertions(+)
 create mode 100644 include/dt-bindings/reset/sama7g5-reset.h

-- 
2.34.1



[PATCH v3 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes

2023-01-04 Thread Sergiu Moga
Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- use usb@


v2 -> v3:
- Nothing


 arch/arm/dts/sam9x60.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index a5c429eb3a..42bf8c6e04 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
#size-cells = <1>;
ranges;
 
+   usb1: usb@60 {
+   compatible = "atmel,at91rm9200-ohci", "usb-ohci";
+   reg = <0x0060 0x10>;
+   clocks = < PMC_TYPE_PERIPHERAL 22>, < 
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
+   clock-names = "ohci_clk", "hclk", "uhpck";
+   status = "disabled";
+   };
+
+   usb2: usb@70 {
+   compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
+   reg = <0x0070 0x10>;
+   clocks = < PMC_TYPE_CORE 8>, < 
PMC_TYPE_PERIPHERAL 22>;
+   clock-names = "usb_clk", "ehci_clk";
+   assigned-clocks = < PMC_TYPE_CORE 8>;
+   assigned-clock-rates = <48000>;
+   status = "disabled";
+   };
+
sdhci0: sdhci-host@8000 {
compatible = "microchip,sam9x60-sdhci";
reg = <0x8000 0x300>;
-- 
2.34.1



[PATCH v2 2/2] reset: at91: Add reset driver for basic assert/deassert operations

2023-01-04 Thread Sergiu Moga
Add support for at91 reset controller's basic assert/deassert
operations. Since this driver conflicts with the
SYSRESET driver because they both bind to the same RSTC node,
implement a custom bind hook that would manually bind the
sysreset driver, if enabled, to the same RSTC DT node.
Furthermore, delete the no longer needed compatibles from the
SYSRESET driver and rename it to make sure than any possible
conflicts are avoided.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
Reviewed-by: Claudiu Beznea 
---

v1 -> v2:
- rebase on u-boot next


 drivers/reset/Kconfig|   8 ++
 drivers/reset/Makefile   |   1 +
 drivers/reset/reset-at91.c   | 141 +++
 drivers/sysreset/sysreset_at91.c |   9 +-
 4 files changed, 151 insertions(+), 8 deletions(-)
 create mode 100644 drivers/reset/reset-at91.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 4cb0ba0850..e4039d7474 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -211,4 +211,12 @@ config RESET_DRA7
help
  Support for TI DRA7-RESET subsystem. Basic Assert/Deassert
  is supported.
+
+config RESET_AT91
+   bool "Enable support for Microchip/Atmel Reset Controller driver"
+   depends on DM_RESET && ARCH_AT91
+   help
+ This enables the Reset Controller driver support for Microchip/Atmel
+ SoCs. Mainly used to expose assert/deassert methods to other drivers
+ that require it.
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 0620b62809..6c8b45ecba 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_ZYNQMP) += reset-zynqmp.o
 obj-$(CONFIG_RESET_DRA7) += reset-dra7.o
+obj-$(CONFIG_RESET_AT91) += reset-at91.o
diff --git a/drivers/reset/reset-at91.c b/drivers/reset/reset-at91.c
new file mode 100644
index 00..165c87acdc
--- /dev/null
+++ b/drivers/reset/reset-at91.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip Reset Controller.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct at91_reset {
+   void __iomem *dev_base;
+   struct at91_reset_data *data;
+};
+
+struct at91_reset_data {
+   u32 n_device_reset;
+   u8 device_reset_min_id;
+   u8 device_reset_max_id;
+};
+
+static const struct at91_reset_data sama7g5_data = {
+   .n_device_reset = 3,
+   .device_reset_min_id = SAMA7G5_RESET_USB_PHY1,
+   .device_reset_max_id = SAMA7G5_RESET_USB_PHY3,
+};
+
+static int at91_rst_update(struct at91_reset *reset, unsigned long id,
+  bool assert)
+{
+   u32 val;
+
+   if (!reset->dev_base)
+   return 0;
+
+   val = readl(reset->dev_base);
+   if (assert)
+   val |= BIT(id);
+   else
+   val &= ~BIT(id);
+   writel(val, reset->dev_base);
+
+   return 0;
+}
+
+static int at91_reset_of_xlate(struct reset_ctl *reset_ctl,
+  struct ofnode_phandle_args *args)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   if (!reset->data->n_device_reset ||
+   args->args[0] < reset->data->device_reset_min_id ||
+   args->args[0] > reset->data->device_reset_max_id)
+   return -EINVAL;
+
+   reset_ctl->id = args->args[0];
+
+   return 0;
+}
+
+static int at91_rst_assert(struct reset_ctl *reset_ctl)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   return at91_rst_update(reset, reset_ctl->id, true);
+}
+
+static int at91_rst_deassert(struct reset_ctl *reset_ctl)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   return at91_rst_update(reset, reset_ctl->id, false);
+}
+
+struct reset_ops at91_reset_ops = {
+   .of_xlate = at91_reset_of_xlate,
+   .rst_assert = at91_rst_assert,
+   .rst_deassert = at91_rst_deassert,
+};
+
+static int at91_reset_probe(struct udevice *dev)
+{
+   struct at91_reset *reset = dev_get_priv(dev);
+   struct clk sclk;
+   int ret;
+
+   reset->data = (struct at91_reset_data *)dev_get_driver_data(dev);
+   reset->dev_base = dev_remap_addr_index(dev, 1);
+   if (reset->data && reset->data->n_device_reset && !reset->dev_base)
+   return -EINVAL;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   return clk_prepare_enable();
+}
+
+static int at91_reset_bind(struct udevice *dev)
+{
+   struct udevice *at91_sysreset;
+
+   if (CONFIG_IS_ENABLED(SYSRESET_AT91))
+   return device_bind_driver_to_node(dev, "at91_sysreset",
+ "at91_sysreset",
+

[PATCH v2 1/2] ARM: at91: add sama7 SFR definitions

2023-01-04 Thread Sergiu Moga
From: Cristian Birsan 

Special Function Registers(SFR) definitions for SAMA7 product family.

Signed-off-by: Cristian Birsan 
Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- nothing


 arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 +
 1 file changed, 59 insertions(+)
 create mode 100644 arch/arm/mach-at91/include/mach/sama7-sfr.h

diff --git a/arch/arm/mach-at91/include/mach/sama7-sfr.h 
b/arch/arm/mach-at91/include/mach/sama7-sfr.h
new file mode 100644
index 00..a987ff5465
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/sama7-sfr.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SFR (Special Function Registers) registers for SAMA7 family.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Cristian Birsan 
+ */
+
+#ifndef _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H
+#define _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H
+
+#define SAMA7_SFR_OHCIICR  0x00/* OHCI INT Configuration Register */
+#define SAMA7_SFR_OHCIISR  0x04/* OHCI INT Status Register */
+/* 0x08 ~ 0xe3: Reserved */
+#define SAMA7_SFR_WPMR 0xe4/* Write Protection Mode Register */
+#define SAMA7_SFR_WPSR 0xe4/* Write Protection Status Register */
+/* 0xec ~ 0x200b: Reserved */
+#define SAMA7_SFR_DEBUG0x200c  /* Debug Register */
+
+/* 0x2010 ~ 0x2027: Reserved */
+#define SAMA7_SFR_EHCIOHCI 0x2020  /* EHCI OHCI Clock Configuration Reg */
+
+#define SAMA7_SFR_HSS_AXI_QOS  0x2028  /* HSS AXI QOS Register */
+#define SAMA7_SFR_UDDRC0x202c  /* UDDRC Register */
+#define SAMA7_SFR_CAN_SRAM_SEL 0x2030  /* CAN SRAM Select. Register */
+/* 0x2034 ~ 0x203f: Reserved */
+
+#define SAMA7_SFR_UTMI00x2040
+#define SAMA7_SFR_UTMI0R(x)(SAMA7_SFR_UTMI0 + 4 * (x))
+
+#define SAMA7_SFR_UTMI0R0  0x2040  /* UTMI0 Configuration Register */
+#define SAMA7_SFR_UTMI0R1  0x2044  /* UTMI1 Configuration Register */
+#define SAMA7_SFR_UTMI0R2  0x2048  /* UTMI2 Configuration Register */
+
+/* Field definitions */
+#define SAMA7_SFR_OHCIICR_ARIE BIT(0)
+#define SAMA7_SFR_OHCIICR_APPSTART BIT(1)
+#define SAMA7_SFR_OHCIICR_USB_SUSP(x)  BIT(8 + (x))
+#define SAMA7_SFR_OHCIICR_USB_SUSPEND  GENMASK(10, 8)
+
+#define SAMA7_SFR_OHCIISR_RIS(x)   BIT(x)
+
+#define SAMA7_SFR_WPMR_WPENBIT(0)
+#define SAMA7_SFR_WPMR_KEY 0x53465200 /* SFR in ASCII*/
+#define SAMA7_SFR_WPMR_WPKEY_MASK  GENMASK(31, 8)
+
+#define SAMA7_SFR_WPSR_WPSRC_MASK  GENMASK(23, 8)
+#define SAMA7_SFR_WPSR_WPVS_MASK   BIT(0)
+
+#define SAMA7_SFR_CAN_SRAM_UPPER(x)BIT(x)
+
+#define SAMA7_SFR_UTMI_RX_VBUS BIT(25) /* VBUS Valid bit */
+#define SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X BIT(23) /* TXPREEMPAMPTUNE 1x */
+#define SAMA7_SFR_UTMI_COMMONONBIT(3)  /* PLL Common 
ON bit */
+
+#define SAMA7_SFR_EHCIOHCI_PHYCLK  BIT(1)  /* Alternate PHY Clk */
+
+#endif /* _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H */
-- 
2.34.1



[PATCH v2 0/2] Add basic reset driver for assert/deassert operations

2023-01-04 Thread Sergiu Moga
This patch series originates from:
https://lists.denx.de/pipermail/u-boot/2022-December/502865.html

Implement a basic driver to enable assert/deassert operations.

v1 -> v2:
- rebase on u-boot next

Cristian Birsan (1):
  ARM: at91: add sama7 SFR definitions

Sergiu Moga (1):
  reset: at91: Add reset driver for basic assert/deassert operations

 arch/arm/mach-at91/include/mach/sama7-sfr.h |  59 
 drivers/reset/Kconfig   |   8 ++
 drivers/reset/Makefile  |   1 +
 drivers/reset/reset-at91.c  | 141 
 drivers/sysreset/sysreset_at91.c|   9 +-
 5 files changed, 210 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/sama7-sfr.h
 create mode 100644 drivers/reset/reset-at91.c

-- 
2.34.1



Re: Pull request for u-boot-nand-20230103

2023-01-04 Thread Tom Rini
On Wed, Jan 04, 2023 at 08:15:02AM +0100, Dario Binacchi wrote:

> Hi Tom,
> 
> The following changes since commit 582e3c9fb2337c2f49faa73ac86dde25f4d56901:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
> (2023-01-02 09:36:13 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
> tags/u-boot-nand-20230103
> 
> for you to fetch changes up to 49bf9d131284b75787dd2e6941d0e9a46d35eeb3:
> 
>   mtd: rawnand: omap_elm: u-boot driver model support (2023-01-03
> 11:21:04 +0100)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14563
> 
> 
> - rawnand: omap_gpmc: driver model support
> 
> 
> Roger Quadros (8):
>   mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
>   mtd: rawnand: nand_base: Allow base driver to be used in SPL
> without nand_bbt
>   dt-bindings: mtd: Add ti, gpmc-nand DT binding documentation
>   mtd: rawnand: omap_gpmc: support u-boot driver model
>   mtd: rawnand: omap_gpmc: Add SPL NAND support
>   mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
>   dt-bindings: mtd: Add ti, elm DT binding documentation
>   mtd: rawnand: omap_elm: u-boot driver model support
> 
>  doc/device-tree-bindings/mtd/ti,elm.yaml   |  72
> +++
>  doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml | 129
> +
>  drivers/mtd/nand/raw/Kconfig   |   9 ++-
>  drivers/mtd/nand/raw/Makefile  |   2 +-
>  drivers/mtd/nand/raw/nand_base.c   |  18 -
>  drivers/mtd/nand/raw/omap_elm.c|  35 -
>  {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h |   6 ++
>  drivers/mtd/nand/raw/omap_gpmc.c   | 441
> +---
>  8 files changed, 604 insertions(+), 108 deletions(-)
>  create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
>  create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
>  rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)

Please rebase this on the next branch.  The release is next Monday and
this is not regression fixes or similar, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Pull request for efi-2023-01-rc5-3

2023-01-04 Thread Heinrich Schuchardt

Dear Tom,

The following changes since commit 582e3c9fb2337c2f49faa73ac86dde25f4d56901:

  Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
(2023-01-02 09:36:13 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2023-01-rc5-3

for you to fetch changes up to 60bba6e2052c281afe401247e10aebcb4c17049b:

  efi_loader: populate console handles in system table (2023-01-04
13:17:42 +0100)

Gitlab CI showed no issues:

https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/14580


Pull request for efi-2023-01-rc5-3

Documentation:

* Describe building documentation

UEFI:

* Add .data section to aarch64 EFI binaries and correct section flags
* Correct sorting of capsules when updating
* Populate console handles in system table

Other:

* Fix description of eth_env_[gs]et_enetaddr() return value
* Avoid endless loop in sound play command


Heinrich Schuchardt (8):
  cmd: avoid endless loop in sound play command
  doc: building documentation
  efi_loader: defines for PE-COFF section flags
  efi_loader: fix building aarch64 EFI binaries
  lib: add function u16_strcasecmp()
  test: unit test for u16_strcasecmp()
  efi_loader: adjust sorting of capsules
  efi_loader: populate console handles in system table

Marek Vasut (1):
  doc: Fix eth_env_[gs]et_enetaddr() return value

 arch/arm/lib/crt0_aarch64_efi.S  | 47 +++--
 arch/arm/lib/elf_aarch64_efi.lds |  6 ++-
 cmd/sound.c  |  4 +-
 doc/build/documentation.rst  | 90

 doc/build/index.rst  |  1 +
 include/asm-generic/pe.h | 13 ++
 include/charset.h| 13 ++
 include/env.h|  4 +-
 lib/charset.c| 26 
 lib/efi_loader/efi_boottime.c|  3 ++
 lib/efi_loader/efi_capsule.c |  9 ++--
 test/unicode_ut.c| 25 +++
 12 files changed, 219 insertions(+), 22 deletions(-)
 create mode 100644 doc/build/documentation.rst


Re: [PATCH v2 1/4] doc: man-page for the part command

2023-01-04 Thread Heinrich Schuchardt

On 12/22/22 11:30, Enric Balletbo i Serra wrote:

Provide a man-page for the part command.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
  - New patch (1) in the series to fix a trivial type
  - New patch (2) in the series to introduce the documentation of the
part type command
  - Fix typo s/partittion/partition/ in commit message
  - Add gpt test for the part type command
  - Add the man-page for part command in doc/usage/cmd

  doc/usage/cmd/part.rst | 97 ++
  1 file changed, 97 insertions(+)
  create mode 100644 doc/usage/cmd/part.rst

diff --git a/doc/usage/cmd/part.rst b/doc/usage/cmd/part.rst
new file mode 100644
index 00..be931e520f
--- /dev/null
+++ b/doc/usage/cmd/part.rst


Thanks for providing this man-page.

The patch lacks an entry in doc/usage/cmd/index.rst.


@@ -0,0 +1,97 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+part command
+===
+
+Synopis
+---
+
+::
+
+part uuid  : [varname]
+part list   [flags] [varname]
+part start
+part size
+part number
+part types
+
+Description
+---
+
+The `part` command is used to manage disk partition related commands.
+
+The 'part uuid' command prints or sets an environment variable to partition 
UUID
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+dev
+device number
+part
+partition number
+varname
+an optional environment variable to store the current partition UUID 
value into.
+
+The 'part list' command prints or sets an environment variable to the list of 
partitions
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+dev
+device number
+part
+partition number
+flags
+-bootable
+lists only bootable partitions
+varname
+an optional environment variable to store the list of partitions value 
into.
+
+The 'part start' sets an environment variable to the start of the partition 
(in blocks),
+part can be either partition number or partition name.
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+dev
+device number
+part
+partition number
+varname
+a variable to store the current start of the partition value into.
+
+The 'part size' sets an environment variable to the size of the partition (in 
blocks),
+part can be either partition number or partition name.
+
+interface
+interface for accessing the block device (mmc, sata, scsi, usb, )
+dev
+device number
+part
+partition number
+varname
+a variable to store the current size of the partition value into.
+
+The 'part number' sets an environment variable to the partition number using 
the partition name,
+part must be specified as partition name.
+
+interfaceH
+interface for accessing the block device (mmc, sata, scsi, usb, )
+dev
+device number
+part
+partition number
+varname
+a variable to store the current partition number value into
+
+The 'part types' command list supported partition table types.
+
+Example
+---
+
+This example shows listing supported partition types::
+
+   U-Boot> part types
+   Supported partition tables: EFI, AMIGA, DOS, ISO, MAC


Please, provide examples for the other sub-commands too.


+
+Return value
+
+
+The return value $? is always 0 (true).


1 (false) is returned in case of errors. Please, have a look at the code.

Best regards

Heinrich



  1   2   >