All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] DM_USB: allow building without OF_CONTROL
@ 2021-06-18 14:57 Pali Rohár
  2021-06-18 14:57 ` [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning Pali Rohár
  2021-06-18 16:38 ` [PATCH 1/2] DM_USB: allow building without OF_CONTROL Tom Rini
  0 siblings, 2 replies; 36+ messages in thread
From: Pali Rohár @ 2021-06-18 14:57 UTC (permalink / raw)
  To: Lokesh Vutla, Tom Rini, Simon Glass
  Cc: Ivaylo Dimitrov, Merlijn Wajer, maemo-leste, u-boot, Pavel Machek

From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>

Currently DM_USB requires OF_CONTROL to be enabled, otherwise link errors
occur. On the other hand OF_CONTROL requires board code to be migrated to
DT, which is not always possible or required.

Fix that by conditionally compiling OF_CONTROL specific sections in USB
related drivers code in the same way like it is done in the other drivers.
Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is not.
Introduce a new Kconfig option OF_NODE used to compile of_node.c in case
OF_CONTROL is not enabled. Fix deprecation warning condition as well.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Pali Rohár <pali@kernel.org>
---
 Makefile                      | 3 +--
 common/usb_hub.c              | 2 ++
 drivers/core/Makefile         | 7 ++++++-
 drivers/usb/Kconfig           | 6 ++++++
 drivers/usb/host/usb-uclass.c | 5 ++++-
 5 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index a73481d18c14..e1cf0200b72c 100644
--- a/Makefile
+++ b/Makefile
@@ -1114,8 +1114,7 @@ ifneq ($(CONFIG_DM),y)
 	@echo >&2 "See doc/driver-model/migration.rst for more info."
 	@echo >&2 "===================================================="
 endif
-	$(call deprecated,CONFIG_DM_USB CONFIG_OF_CONTROL CONFIG_BLK,\
-		USB,v2019.07,$(CONFIG_USB))
+	$(call deprecated,CONFIG_DM_USB CONFIG_BLK,USB,v2019.07,$(CONFIG_USB))
 	$(call deprecated,CONFIG_DM_PCI,PCI,v2019.07,$(CONFIG_PCI))
 	$(call deprecated,CONFIG_DM_VIDEO,video,v2019.07,\
 		$(CONFIG_LCD)$(CONFIG_VIDEO))
diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a188ca64..c6b042a68440 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -956,7 +956,9 @@ U_BOOT_DRIVER(usb_generic_hub) = {
 UCLASS_DRIVER(usb_hub) = {
 	.id		= UCLASS_USB_HUB,
 	.name		= "usb_hub",
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 	.post_bind	= dm_scan_fdt_dev,
+#endif
 	.post_probe	= usb_hub_post_probe,
 	.child_pre_probe	= usb_child_pre_probe,
 	.per_child_auto	= sizeof(struct usb_device),
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index 5edd4e413576..2cf5873a3278 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -15,6 +15,11 @@ obj-$(CONFIG_$(SPL_)OF_LIVE) += of_access.o of_addr.o
 ifndef CONFIG_DM_DEV_READ_INLINE
 obj-$(CONFIG_OF_CONTROL) += read.o
 endif
-obj-$(CONFIG_OF_CONTROL) += of_extra.o ofnode.o read_extra.o
+obj-$(CONFIG_OF_CONTROL) += of_extra.o read_extra.o
+ifdef CONFIG_OF_NODE
+obj-y += ofnode.o
+else
+obj-$(CONFIG_OF_CONTROL) += ofnode.o
+endif
 
 ccflags-$(CONFIG_DM_DEBUG) += -DDEBUG
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index f6975730bf8d..cb0593a724f0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -33,9 +33,15 @@ menuconfig USB
 
 if USB
 
+config OF_NODE
+	bool
+	default n
+
 config DM_USB
 	bool "Enable driver model for USB"
 	depends on USB && DM
+	select OF_LIBFDT if !OF_CONTROL
+	select OF_NODE if !OF_CONTROL
 	help
 	  Enable driver model for USB. The USB interface is then implemented
 	  by the USB uclass. Multiple USB controllers of different types
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index e3b616c3266a..71dc578550f5 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -770,6 +770,7 @@ int usb_detect_change(void)
 
 static int usb_child_post_bind(struct udevice *dev)
 {
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 	struct usb_dev_plat *plat = dev_get_parent_plat(dev);
 	int val;
 
@@ -787,7 +788,7 @@ static int usb_child_post_bind(struct udevice *dev)
 		plat->id.match_flags |= USB_DEVICE_ID_MATCH_INT_CLASS;
 		plat->id.bInterfaceClass = val;
 	}
-
+#endif
 	return 0;
 }
 
@@ -848,7 +849,9 @@ UCLASS_DRIVER(usb) = {
 	.id		= UCLASS_USB,
 	.name		= "usb",
 	.flags		= DM_UC_FLAG_SEQ_ALIAS,
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 	.post_bind	= dm_scan_fdt_dev,
+#endif
 	.priv_auto	= sizeof(struct usb_uclass_priv),
 	.per_child_auto	= sizeof(struct usb_device),
 	.per_device_auto	= sizeof(struct usb_bus_priv),
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning
  2021-06-18 14:57 [PATCH 1/2] DM_USB: allow building without OF_CONTROL Pali Rohár
@ 2021-06-18 14:57 ` Pali Rohár
  2021-06-26 18:31   ` Simon Glass
  2021-06-18 16:38 ` [PATCH 1/2] DM_USB: allow building without OF_CONTROL Tom Rini
  1 sibling, 1 reply; 36+ messages in thread
From: Pali Rohár @ 2021-06-18 14:57 UTC (permalink / raw)
  To: Lokesh Vutla, Tom Rini, Simon Glass
  Cc: Ivaylo Dimitrov, Merlijn Wajer, maemo-leste, u-boot, Pavel Machek

From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>

Also disable various options that are auto-enabled by default, but not
really applicable to RX-51.

Enable CONFIG_SYS_THUMB_BUILD, otherwise the resulting binary becomes too
large to be useful on a real hardware.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Pali Rohár <pali@kernel.org>
---
 configs/nokia_rx51_defconfig | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 981e6f95cb1f..0611d002908f 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -1,5 +1,4 @@
 CONFIG_ARM=y
-# CONFIG_SYS_THUMB_BUILD is not set
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_SYS_TEXT_BASE=0x80008000
 CONFIG_NR_DRAM_BANKS=2
@@ -25,6 +24,7 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_BOOTM_VXWORKS is not set
 CONFIG_CMD_BOOTMENU=y
 # CONFIG_CMD_ELF is not set
+# CONFIG_CMD_FDT is not set
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_EXPORTENV is not set
@@ -62,6 +62,7 @@ CONFIG_CONS_INDEX=3
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_CFB_CONSOLE=y
@@ -71,3 +72,5 @@ CONFIG_SPLASH_SCREEN=y
 CONFIG_WATCHDOG_TIMEOUT_MSECS=31000
 CONFIG_WDT=y
 # CONFIG_GZIP is not set
+# CONFIG_OF_LIBFDT_OVERLAY is not set
+# CONFIG_EFI_LOADER is not set
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-18 14:57 [PATCH 1/2] DM_USB: allow building without OF_CONTROL Pali Rohár
  2021-06-18 14:57 ` [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning Pali Rohár
@ 2021-06-18 16:38 ` Tom Rini
  2021-06-19  2:23   ` Marek Vasut
  1 sibling, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-18 16:38 UTC (permalink / raw)
  To: Pali Rohár, Marek Vasut
  Cc: Lokesh Vutla, Simon Glass, Ivaylo Dimitrov, Merlijn Wajer,
	maemo-leste, u-boot, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

+Marek

On Fri, Jun 18, 2021 at 04:57:23PM +0200, Pali Rohár wrote:

> From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> 
> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link errors
> occur. On the other hand OF_CONTROL requires board code to be migrated to
> DT, which is not always possible or required.
> 
> Fix that by conditionally compiling OF_CONTROL specific sections in USB
> related drivers code in the same way like it is done in the other drivers.
> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is not.
> Introduce a new Kconfig option OF_NODE used to compile of_node.c in case
> OF_CONTROL is not enabled. Fix deprecation warning condition as well.
> 
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Tested-by: Pali Rohár <pali@kernel.org>
> ---
>  Makefile                      | 3 +--
>  common/usb_hub.c              | 2 ++
>  drivers/core/Makefile         | 7 ++++++-
>  drivers/usb/Kconfig           | 6 ++++++
>  drivers/usb/host/usb-uclass.c | 5 ++++-
>  5 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index a73481d18c14..e1cf0200b72c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1114,8 +1114,7 @@ ifneq ($(CONFIG_DM),y)
>  	@echo >&2 "See doc/driver-model/migration.rst for more info."
>  	@echo >&2 "===================================================="
>  endif
> -	$(call deprecated,CONFIG_DM_USB CONFIG_OF_CONTROL CONFIG_BLK,\
> -		USB,v2019.07,$(CONFIG_USB))
> +	$(call deprecated,CONFIG_DM_USB CONFIG_BLK,USB,v2019.07,$(CONFIG_USB))
>  	$(call deprecated,CONFIG_DM_PCI,PCI,v2019.07,$(CONFIG_PCI))
>  	$(call deprecated,CONFIG_DM_VIDEO,video,v2019.07,\
>  		$(CONFIG_LCD)$(CONFIG_VIDEO))
> diff --git a/common/usb_hub.c b/common/usb_hub.c
> index ba11a188ca64..c6b042a68440 100644
> --- a/common/usb_hub.c
> +++ b/common/usb_hub.c
> @@ -956,7 +956,9 @@ U_BOOT_DRIVER(usb_generic_hub) = {
>  UCLASS_DRIVER(usb_hub) = {
>  	.id		= UCLASS_USB_HUB,
>  	.name		= "usb_hub",
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>  	.post_bind	= dm_scan_fdt_dev,
> +#endif
>  	.post_probe	= usb_hub_post_probe,
>  	.child_pre_probe	= usb_child_pre_probe,
>  	.per_child_auto	= sizeof(struct usb_device),
> diff --git a/drivers/core/Makefile b/drivers/core/Makefile
> index 5edd4e413576..2cf5873a3278 100644
> --- a/drivers/core/Makefile
> +++ b/drivers/core/Makefile
> @@ -15,6 +15,11 @@ obj-$(CONFIG_$(SPL_)OF_LIVE) += of_access.o of_addr.o
>  ifndef CONFIG_DM_DEV_READ_INLINE
>  obj-$(CONFIG_OF_CONTROL) += read.o
>  endif
> -obj-$(CONFIG_OF_CONTROL) += of_extra.o ofnode.o read_extra.o
> +obj-$(CONFIG_OF_CONTROL) += of_extra.o read_extra.o
> +ifdef CONFIG_OF_NODE
> +obj-y += ofnode.o
> +else
> +obj-$(CONFIG_OF_CONTROL) += ofnode.o
> +endif
>  
>  ccflags-$(CONFIG_DM_DEBUG) += -DDEBUG
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index f6975730bf8d..cb0593a724f0 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -33,9 +33,15 @@ menuconfig USB
>  
>  if USB
>  
> +config OF_NODE
> +	bool
> +	default n
> +
>  config DM_USB
>  	bool "Enable driver model for USB"
>  	depends on USB && DM
> +	select OF_LIBFDT if !OF_CONTROL
> +	select OF_NODE if !OF_CONTROL
>  	help
>  	  Enable driver model for USB. The USB interface is then implemented
>  	  by the USB uclass. Multiple USB controllers of different types
> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
> index e3b616c3266a..71dc578550f5 100644
> --- a/drivers/usb/host/usb-uclass.c
> +++ b/drivers/usb/host/usb-uclass.c
> @@ -770,6 +770,7 @@ int usb_detect_change(void)
>  
>  static int usb_child_post_bind(struct udevice *dev)
>  {
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>  	struct usb_dev_plat *plat = dev_get_parent_plat(dev);
>  	int val;
>  
> @@ -787,7 +788,7 @@ static int usb_child_post_bind(struct udevice *dev)
>  		plat->id.match_flags |= USB_DEVICE_ID_MATCH_INT_CLASS;
>  		plat->id.bInterfaceClass = val;
>  	}
> -
> +#endif
>  	return 0;
>  }
>  
> @@ -848,7 +849,9 @@ UCLASS_DRIVER(usb) = {
>  	.id		= UCLASS_USB,
>  	.name		= "usb",
>  	.flags		= DM_UC_FLAG_SEQ_ALIAS,
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>  	.post_bind	= dm_scan_fdt_dev,
> +#endif
>  	.priv_auto	= sizeof(struct usb_uclass_priv),
>  	.per_child_auto	= sizeof(struct usb_device),
>  	.per_device_auto	= sizeof(struct usb_bus_priv),
> -- 
> 2.20.1
> 

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-18 16:38 ` [PATCH 1/2] DM_USB: allow building without OF_CONTROL Tom Rini
@ 2021-06-19  2:23   ` Marek Vasut
  2021-06-19  6:14     ` Ivaylo Dimitrov
  0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2021-06-19  2:23 UTC (permalink / raw)
  To: Tom Rini, Pali Rohár
  Cc: Lokesh Vutla, Simon Glass, Ivaylo Dimitrov, Merlijn Wajer,
	maemo-leste, u-boot, Pavel Machek

On 6/18/21 6:38 PM, Tom Rini wrote:
> +Marek
> 
> On Fri, Jun 18, 2021 at 04:57:23PM +0200, Pali Rohár wrote:
> 
>> From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>>
>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link errors
>> occur. On the other hand OF_CONTROL requires board code to be migrated to
>> DT, which is not always possible or required.
>>
>> Fix that by conditionally compiling OF_CONTROL specific sections in USB
>> related drivers code in the same way like it is done in the other drivers.
>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is not.
>> Introduce a new Kconfig option OF_NODE used to compile of_node.c in case
>> OF_CONTROL is not enabled. Fix deprecation warning condition as well.

So, what is the use case of this? Why not just enable DM_USB and 
OF_CONTROL ?

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19  2:23   ` Marek Vasut
@ 2021-06-19  6:14     ` Ivaylo Dimitrov
  2021-06-19 18:17       ` Marek Vasut
  0 siblings, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-19  6:14 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Tom Rini, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, maemo-leste, u-boot, Pavel Machek

Hi Marek,

On 19.06.21 г. 5:23 ч., Marek Vasut wrote:
> On 6/18/21 6:38 PM, Tom Rini wrote:
>> +Marek
>>
>> On Fri, Jun 18, 2021 at 04:57:23PM +0200, Pali Rohár wrote:
>>
>>> From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>>>
>>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link 
>>> errors
>>> occur. On the other hand OF_CONTROL requires board code to be 
>>> migrated to
>>> DT, which is not always possible or required.
>>>
>>> Fix that by conditionally compiling OF_CONTROL specific sections in USB
>>> related drivers code in the same way like it is done in the other 
>>> drivers.
>>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is not.
>>> Introduce a new Kconfig option OF_NODE used to compile of_node.c in case
>>> OF_CONTROL is not enabled. Fix deprecation warning condition as well.
> 
> So, what is the use case of this? Why not just enable DM_USB and 
> OF_CONTROL ?

OF_CONTROL requires migration to device-tree.

Regards,
Ivo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19  6:14     ` Ivaylo Dimitrov
@ 2021-06-19 18:17       ` Marek Vasut
  2021-06-19 19:33         ` Ivaylo Dimitrov
  0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2021-06-19 18:17 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Tom Rini, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, maemo-leste, u-boot, Pavel Machek

On 6/19/21 8:14 AM, Ivaylo Dimitrov wrote:
> Hi Marek,

Hi,

[...]

>>>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link 
>>>> errors
>>>> occur. On the other hand OF_CONTROL requires board code to be 
>>>> migrated to
>>>> DT, which is not always possible or required.
>>>>
>>>> Fix that by conditionally compiling OF_CONTROL specific sections in USB
>>>> related drivers code in the same way like it is done in the other 
>>>> drivers.
>>>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is 
>>>> not.
>>>> Introduce a new Kconfig option OF_NODE used to compile of_node.c in 
>>>> case
>>>> OF_CONTROL is not enabled. Fix deprecation warning condition as well.
>>
>> So, what is the use case of this? Why not just enable DM_USB and 
>> OF_CONTROL ?
> 
> OF_CONTROL requires migration to device-tree.

That's where the supported platforms are heading anyway. Or is there 
some issue with switching the platform you use over to DT ?

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19 18:17       ` Marek Vasut
@ 2021-06-19 19:33         ` Ivaylo Dimitrov
  2021-06-19 19:38           ` Marek Vasut
  0 siblings, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-19 19:33 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Tom Rini, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, maemo-leste, u-boot, Pavel Machek

Hi,

On 19.06.21 г. 21:17 ч., Marek Vasut wrote:
> On 6/19/21 8:14 AM, Ivaylo Dimitrov wrote:
>> Hi Marek,
> 
> Hi,
> 
> [...]
> 
>>>>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link 
>>>>> errors
>>>>> occur. On the other hand OF_CONTROL requires board code to be 
>>>>> migrated to
>>>>> DT, which is not always possible or required.
>>>>>
>>>>> Fix that by conditionally compiling OF_CONTROL specific sections in 
>>>>> USB
>>>>> related drivers code in the same way like it is done in the other 
>>>>> drivers.
>>>>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL is 
>>>>> not.
>>>>> Introduce a new Kconfig option OF_NODE used to compile of_node.c in 
>>>>> case
>>>>> OF_CONTROL is not enabled. Fix deprecation warning condition as well.
>>>
>>> So, what is the use case of this? Why not just enable DM_USB and 
>>> OF_CONTROL ?
>>
>> OF_CONTROL requires migration to device-tree.
> 
> That's where the supported platforms are heading anyway. Or is there 
> some issue with switching the platform you use over to DT ?

OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia rx-51 
board). For various reasons I am not going to discuss (1), migration to 
DM was delayed to the point where we saw "[PATCH] arm: Remove nokia_rx51 
board" with a commit message "This board has not been converted to 
CONFIG_DM_USB by the deadline. Remove it." posted. The missing pieces 
were WDT (a patch is already merged in -next) and DM_USB. The board 
itself does not support host mode, but USB TTY is very useful for 
debugging purposes. The particular task I am after is USB DM migration 
and the $subject patch allows this to be achieved with relatively little 
effort (a couple of defconfig changes), incomparable with the effort 
needed for migration to DT. As we are already past the DM migration 
deadline I think it makes sense to fulfil its requirements before 
undertaking such a big task like migration to DT.

Regards,
Ivo

(1) https://www.mail-archive.com/u-boot@lists.denx.de/msg409064.html

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19 19:33         ` Ivaylo Dimitrov
@ 2021-06-19 19:38           ` Marek Vasut
  2021-06-19 20:15             ` Ivaylo Dimitrov
  0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2021-06-19 19:38 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Tom Rini, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

On 6/19/21 9:33 PM, Ivaylo Dimitrov wrote:
> Hi,

Hi,

>>>>>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise link 
>>>>>> errors
>>>>>> occur. On the other hand OF_CONTROL requires board code to be 
>>>>>> migrated to
>>>>>> DT, which is not always possible or required.
>>>>>>
>>>>>> Fix that by conditionally compiling OF_CONTROL specific sections 
>>>>>> in USB
>>>>>> related drivers code in the same way like it is done in the other 
>>>>>> drivers.
>>>>>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL 
>>>>>> is not.
>>>>>> Introduce a new Kconfig option OF_NODE used to compile of_node.c 
>>>>>> in case
>>>>>> OF_CONTROL is not enabled. Fix deprecation warning condition as well.
>>>>
>>>> So, what is the use case of this? Why not just enable DM_USB and 
>>>> OF_CONTROL ?
>>>
>>> OF_CONTROL requires migration to device-tree.
>>
>> That's where the supported platforms are heading anyway. Or is there 
>> some issue with switching the platform you use over to DT ?
> 
> OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia rx-51 
> board). For various reasons I am not going to discuss (1), migration to 
> DM was delayed to the point where we saw "[PATCH] arm: Remove nokia_rx51 
> board" with a commit message "This board has not been converted to 
> CONFIG_DM_USB by the deadline. Remove it." posted. The missing pieces 
> were WDT (a patch is already merged in -next) and DM_USB. The board 
> itself does not support host mode, but USB TTY is very useful for 
> debugging purposes. The particular task I am after is USB DM migration 
> and the $subject patch allows this to be achieved with relatively little 
> effort (a couple of defconfig changes), incomparable with the effort 
> needed for migration to DT. As we are already past the DM migration 
> deadline I think it makes sense to fulfil its requirements before 
> undertaking such a big task like migration to DT.

This sounds like a workaround though. Can you instead do the full 
conversion of the board? I am sure the board removal patch can be 
postponed if there is plan to convert it.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19 19:38           ` Marek Vasut
@ 2021-06-19 20:15             ` Ivaylo Dimitrov
  2021-06-19 20:51               ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-19 20:15 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Tom Rini, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek



On 19.06.21 г. 22:38 ч., Marek Vasut wrote:
> On 6/19/21 9:33 PM, Ivaylo Dimitrov wrote:
>> Hi,
> 
> Hi,
> 
>>>>>>> Currently DM_USB requires OF_CONTROL to be enabled, otherwise 
>>>>>>> link errors
>>>>>>> occur. On the other hand OF_CONTROL requires board code to be 
>>>>>>> migrated to
>>>>>>> DT, which is not always possible or required.
>>>>>>>
>>>>>>> Fix that by conditionally compiling OF_CONTROL specific sections 
>>>>>>> in USB
>>>>>>> related drivers code in the same way like it is done in the other 
>>>>>>> drivers.
>>>>>>> Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL 
>>>>>>> is not.
>>>>>>> Introduce a new Kconfig option OF_NODE used to compile of_node.c 
>>>>>>> in case
>>>>>>> OF_CONTROL is not enabled. Fix deprecation warning condition as 
>>>>>>> well.
>>>>>
>>>>> So, what is the use case of this? Why not just enable DM_USB and 
>>>>> OF_CONTROL ?
>>>>
>>>> OF_CONTROL requires migration to device-tree.
>>>
>>> That's where the supported platforms are heading anyway. Or is there 
>>> some issue with switching the platform you use over to DT ?
>>
>> OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia rx-51 
>> board). For various reasons I am not going to discuss (1), migration 
>> to DM was delayed to the point where we saw "[PATCH] arm: Remove 
>> nokia_rx51 board" with a commit message "This board has not been 
>> converted to CONFIG_DM_USB by the deadline. Remove it." posted. The 
>> missing pieces were WDT (a patch is already merged in -next) and 
>> DM_USB. The board itself does not support host mode, but USB TTY is 
>> very useful for debugging purposes. The particular task I am after is 
>> USB DM migration and the $subject patch allows this to be achieved 
>> with relatively little effort (a couple of defconfig changes), 
>> incomparable with the effort needed for migration to DT. As we are 
>> already past the DM migration deadline I think it makes sense to 
>> fulfil its requirements before undertaking such a big task like 
>> migration to DT.
> 
> This sounds like a workaround though. Can you instead do the full 
> conversion of the board? I am sure the board removal patch can be 
> postponed if there is plan to convert it.

Hard to say if migration to device-tree is even possible on N900 ATM, 
enabling OF_CONTROL increases the size of the produced binary with some 
100k (.dtb not included), making the size of the binary way above our 
budget of ~256k. Sure, board config does not enable -mthumb, but omap3 
in rx-51 suffers from ARM errata 430973 and noone can guarantee we're 
not going to see SIGILL faults if we enable it. Which it seems we are 
forced to do even with DM_USB migration only.

Re workaround - I took examples of #ifdef's from the current u-boot code 
(mmc, i2c, etc.) so workaround or not, it is no different to what the 
other drivers are doing.

I don't really understand where this requirement to convert to DTS comes 
from - will boards that are not converted be removed at some point? When 
is that deadline if exists? If there is no such deadline, why shall we 
spend who knows how many hours just because "you know, it sounds like a 
good idea to convert to DTS"? You understand this is not a trivial task 
and given the pace rx-51 patches were reviewed lately, it will easily 
take 2 years to do that conversion.

To sum it up - maybe I can do a full DTS migration, but I don't see a 
point in doing it ATM. The $subject patch allows rx-51 to be fully 
migrated to DM and does nothing different to what already is done all 
over the place.

Regards,
Ivo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19 20:15             ` Ivaylo Dimitrov
@ 2021-06-19 20:51               ` Tom Rini
  2021-06-20  3:52                 ` Marek Vasut
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-19 20:51 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Marek Vasut, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 5170 bytes --]

On Sat, Jun 19, 2021 at 11:15:50PM +0300, Ivaylo Dimitrov wrote:
> 
> 
> On 19.06.21 г. 22:38 ч., Marek Vasut wrote:
> > On 6/19/21 9:33 PM, Ivaylo Dimitrov wrote:
> > > Hi,
> > 
> > Hi,
> > 
> > > > > > > > Currently DM_USB requires OF_CONTROL to be
> > > > > > > > enabled, otherwise link errors
> > > > > > > > occur. On the other hand OF_CONTROL requires
> > > > > > > > board code to be migrated to
> > > > > > > > DT, which is not always possible or required.
> > > > > > > > 
> > > > > > > > Fix that by conditionally compiling OF_CONTROL
> > > > > > > > specific sections in USB
> > > > > > > > related drivers code in the same way like it is
> > > > > > > > done in the other drivers.
> > > > > > > > Also, auto select OF_LIBFDT if DM_USB is
> > > > > > > > selected but OF_CONTROL is not.
> > > > > > > > Introduce a new Kconfig option OF_NODE used to
> > > > > > > > compile of_node.c in case
> > > > > > > > OF_CONTROL is not enabled. Fix deprecation
> > > > > > > > warning condition as well.
> > > > > > 
> > > > > > So, what is the use case of this? Why not just enable
> > > > > > DM_USB and OF_CONTROL ?
> > > > > 
> > > > > OF_CONTROL requires migration to device-tree.
> > > > 
> > > > That's where the supported platforms are heading anyway. Or is
> > > > there some issue with switching the platform you use over to DT
> > > > ?
> > > 
> > > OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia
> > > rx-51 board). For various reasons I am not going to discuss (1),
> > > migration to DM was delayed to the point where we saw "[PATCH] arm:
> > > Remove nokia_rx51 board" with a commit message "This board has not
> > > been converted to CONFIG_DM_USB by the deadline. Remove it." posted.
> > > The missing pieces were WDT (a patch is already merged in -next) and
> > > DM_USB. The board itself does not support host mode, but USB TTY is
> > > very useful for debugging purposes. The particular task I am after
> > > is USB DM migration and the $subject patch allows this to be
> > > achieved with relatively little effort (a couple of defconfig
> > > changes), incomparable with the effort needed for migration to DT.
> > > As we are already past the DM migration deadline I think it makes
> > > sense to fulfil its requirements before undertaking such a big task
> > > like migration to DT.
> > 
> > This sounds like a workaround though. Can you instead do the full
> > conversion of the board? I am sure the board removal patch can be
> > postponed if there is plan to convert it.
> 
> Hard to say if migration to device-tree is even possible on N900 ATM,
> enabling OF_CONTROL increases the size of the produced binary with some 100k
> (.dtb not included), making the size of the binary way above our budget of
> ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51
> suffers from ARM errata 430973 and noone can guarantee we're not going to
> see SIGILL faults if we enable it. Which it seems we are forced to do even
> with DM_USB migration only.

Note that yes, it should be safe to enable thumb mode, but run time
confirmation would be good.

> Re workaround - I took examples of #ifdef's from the current u-boot code
> (mmc, i2c, etc.) so workaround or not, it is no different to what the other
> drivers are doing.
> 
> I don't really understand where this requirement to convert to DTS comes
> from - will boards that are not converted be removed at some point? When is
> that deadline if exists? If there is no such deadline, why shall we spend
> who knows how many hours just because "you know, it sounds like a good idea
> to convert to DTS"? You understand this is not a trivial task and given the
> pace rx-51 patches were reviewed lately, it will easily take 2 years to do
> that conversion.
> 
> To sum it up - maybe I can do a full DTS migration, but I don't see a point
> in doing it ATM. The $subject patch allows rx-51 to be fully migrated to DM
> and does nothing different to what already is done all over the place.

So, there are deadlines for migration to device model.  The argument
being put forth by the Nokia RX51 folks is that to quote
include/dm/platdata.h (and yes, they aren't using U_BOOT_DRVINFO in this
case, but...):
/**
 * NOTE: Avoid using these except in extreme circumstances, where device tree
 * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
 * available). U-Boot's driver model uses device tree for configuration.
 *
 * When of-platdata is in use, U_BOOT_DRVINFO() cannot be used outside of the
 * dt-plat.c file created by dtoc
 */
that's them, and it's not an SPL case but full U-Boot and a fixed size
amount of the flash that they can use, no arguing.  So we need to make
changes in subsystems they use so that they can continue to work.

So, are the changes being proposed to the generic USB code, such that
DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
that's not set yet, but that's not to say never, it's just not been set,
so getting ahead of problems here would be appreciated) that can also be
enabled, OK?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-19 20:51               ` Tom Rini
@ 2021-06-20  3:52                 ` Marek Vasut
  2021-06-20 15:54                   ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2021-06-20  3:52 UTC (permalink / raw)
  To: Tom Rini, Ivaylo Dimitrov
  Cc: Pali Rohár, Lokesh Vutla, Simon Glass, Merlijn Wajer,
	u-boot, Pavel Machek

On 6/19/21 10:51 PM, Tom Rini wrote:

Hi,

>>>>>>>>> Currently DM_USB requires OF_CONTROL to be
>>>>>>>>> enabled, otherwise link errors
>>>>>>>>> occur. On the other hand OF_CONTROL requires
>>>>>>>>> board code to be migrated to
>>>>>>>>> DT, which is not always possible or required.
>>>>>>>>>
>>>>>>>>> Fix that by conditionally compiling OF_CONTROL
>>>>>>>>> specific sections in USB
>>>>>>>>> related drivers code in the same way like it is
>>>>>>>>> done in the other drivers.
>>>>>>>>> Also, auto select OF_LIBFDT if DM_USB is
>>>>>>>>> selected but OF_CONTROL is not.
>>>>>>>>> Introduce a new Kconfig option OF_NODE used to
>>>>>>>>> compile of_node.c in case
>>>>>>>>> OF_CONTROL is not enabled. Fix deprecation
>>>>>>>>> warning condition as well.
>>>>>>>
>>>>>>> So, what is the use case of this? Why not just enable
>>>>>>> DM_USB and OF_CONTROL ?
>>>>>>
>>>>>> OF_CONTROL requires migration to device-tree.
>>>>>
>>>>> That's where the supported platforms are heading anyway. Or is
>>>>> there some issue with switching the platform you use over to DT
>>>>> ?
>>>>
>>>> OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia
>>>> rx-51 board). For various reasons I am not going to discuss (1),
>>>> migration to DM was delayed to the point where we saw "[PATCH] arm:
>>>> Remove nokia_rx51 board" with a commit message "This board has not
>>>> been converted to CONFIG_DM_USB by the deadline. Remove it." posted.
>>>> The missing pieces were WDT (a patch is already merged in -next) and
>>>> DM_USB. The board itself does not support host mode, but USB TTY is
>>>> very useful for debugging purposes. The particular task I am after
>>>> is USB DM migration and the $subject patch allows this to be
>>>> achieved with relatively little effort (a couple of defconfig
>>>> changes), incomparable with the effort needed for migration to DT.
>>>> As we are already past the DM migration deadline I think it makes
>>>> sense to fulfil its requirements before undertaking such a big task
>>>> like migration to DT.
>>>
>>> This sounds like a workaround though. Can you instead do the full
>>> conversion of the board? I am sure the board removal patch can be
>>> postponed if there is plan to convert it.
>>
>> Hard to say if migration to device-tree is even possible on N900 ATM,
>> enabling OF_CONTROL increases the size of the produced binary with some 100k
>> (.dtb not included), making the size of the binary way above our budget of
>> ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51
>> suffers from ARM errata 430973 and noone can guarantee we're not going to
>> see SIGILL faults if we enable it. Which it seems we are forced to do even
>> with DM_USB migration only.
> 
> Note that yes, it should be safe to enable thumb mode, but run time
> confirmation would be good.
> 
>> Re workaround - I took examples of #ifdef's from the current u-boot code
>> (mmc, i2c, etc.) so workaround or not, it is no different to what the other
>> drivers are doing.
>>
>> I don't really understand where this requirement to convert to DTS comes
>> from - will boards that are not converted be removed at some point? When is
>> that deadline if exists? If there is no such deadline, why shall we spend
>> who knows how many hours just because "you know, it sounds like a good idea
>> to convert to DTS"? You understand this is not a trivial task and given the
>> pace rx-51 patches were reviewed lately, it will easily take 2 years to do
>> that conversion.
>>
>> To sum it up - maybe I can do a full DTS migration, but I don't see a point
>> in doing it ATM. The $subject patch allows rx-51 to be fully migrated to DM
>> and does nothing different to what already is done all over the place.
> 
> So, there are deadlines for migration to device model.  The argument
> being put forth by the Nokia RX51 folks is that to quote
> include/dm/platdata.h (and yes, they aren't using U_BOOT_DRVINFO in this
> case, but...):
> /**
>   * NOTE: Avoid using these except in extreme circumstances, where device tree
>   * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
>   * available). U-Boot's driver model uses device tree for configuration.
>   *
>   * When of-platdata is in use, U_BOOT_DRVINFO() cannot be used outside of the
>   * dt-plat.c file created by dtoc
>   */
> that's them, and it's not an SPL case but full U-Boot and a fixed size
> amount of the flash that they can use, no arguing.

As far as I understand, the RX51 has gigabytes of eMMC storage, so it 
can use SPL just like any other OMAP3 board.

> So we need to make
> changes in subsystems they use so that they can continue to work.
> 
> So, are the changes being proposed to the generic USB code, such that
> DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> that's not set yet, but that's not to say never, it's just not been set,
> so getting ahead of problems here would be appreciated) that can also be
> enabled, OK?

I am confused by this reply. I noticed a lot of boards were removed over 
time because they were not converted to DM/DT, and to get rid of all the 
ifdefs, but now it seems the direction has been completely reversed and 
we should start adding back all the ifdefs to cater for boards which are 
not converted instead of fixing the boards ?

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-20  3:52                 ` Marek Vasut
@ 2021-06-20 15:54                   ` Tom Rini
  2021-06-20 19:43                     ` Marek Vasut
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-20 15:54 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Ivaylo Dimitrov, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 6547 bytes --]

On Sun, Jun 20, 2021 at 05:52:03AM +0200, Marek Vasut wrote:
> On 6/19/21 10:51 PM, Tom Rini wrote:
> 
> Hi,
> 
> > > > > > > > > > Currently DM_USB requires OF_CONTROL to be
> > > > > > > > > > enabled, otherwise link errors
> > > > > > > > > > occur. On the other hand OF_CONTROL requires
> > > > > > > > > > board code to be migrated to
> > > > > > > > > > DT, which is not always possible or required.
> > > > > > > > > > 
> > > > > > > > > > Fix that by conditionally compiling OF_CONTROL
> > > > > > > > > > specific sections in USB
> > > > > > > > > > related drivers code in the same way like it is
> > > > > > > > > > done in the other drivers.
> > > > > > > > > > Also, auto select OF_LIBFDT if DM_USB is
> > > > > > > > > > selected but OF_CONTROL is not.
> > > > > > > > > > Introduce a new Kconfig option OF_NODE used to
> > > > > > > > > > compile of_node.c in case
> > > > > > > > > > OF_CONTROL is not enabled. Fix deprecation
> > > > > > > > > > warning condition as well.
> > > > > > > > 
> > > > > > > > So, what is the use case of this? Why not just enable
> > > > > > > > DM_USB and OF_CONTROL ?
> > > > > > > 
> > > > > > > OF_CONTROL requires migration to device-tree.
> > > > > > 
> > > > > > That's where the supported platforms are heading anyway. Or is
> > > > > > there some issue with switching the platform you use over to DT
> > > > > > ?
> > > > > 
> > > > > OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia
> > > > > rx-51 board). For various reasons I am not going to discuss (1),
> > > > > migration to DM was delayed to the point where we saw "[PATCH] arm:
> > > > > Remove nokia_rx51 board" with a commit message "This board has not
> > > > > been converted to CONFIG_DM_USB by the deadline. Remove it." posted.
> > > > > The missing pieces were WDT (a patch is already merged in -next) and
> > > > > DM_USB. The board itself does not support host mode, but USB TTY is
> > > > > very useful for debugging purposes. The particular task I am after
> > > > > is USB DM migration and the $subject patch allows this to be
> > > > > achieved with relatively little effort (a couple of defconfig
> > > > > changes), incomparable with the effort needed for migration to DT.
> > > > > As we are already past the DM migration deadline I think it makes
> > > > > sense to fulfil its requirements before undertaking such a big task
> > > > > like migration to DT.
> > > > 
> > > > This sounds like a workaround though. Can you instead do the full
> > > > conversion of the board? I am sure the board removal patch can be
> > > > postponed if there is plan to convert it.
> > > 
> > > Hard to say if migration to device-tree is even possible on N900 ATM,
> > > enabling OF_CONTROL increases the size of the produced binary with some 100k
> > > (.dtb not included), making the size of the binary way above our budget of
> > > ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51
> > > suffers from ARM errata 430973 and noone can guarantee we're not going to
> > > see SIGILL faults if we enable it. Which it seems we are forced to do even
> > > with DM_USB migration only.
> > 
> > Note that yes, it should be safe to enable thumb mode, but run time
> > confirmation would be good.
> > 
> > > Re workaround - I took examples of #ifdef's from the current u-boot code
> > > (mmc, i2c, etc.) so workaround or not, it is no different to what the other
> > > drivers are doing.
> > > 
> > > I don't really understand where this requirement to convert to DTS comes
> > > from - will boards that are not converted be removed at some point? When is
> > > that deadline if exists? If there is no such deadline, why shall we spend
> > > who knows how many hours just because "you know, it sounds like a good idea
> > > to convert to DTS"? You understand this is not a trivial task and given the
> > > pace rx-51 patches were reviewed lately, it will easily take 2 years to do
> > > that conversion.
> > > 
> > > To sum it up - maybe I can do a full DTS migration, but I don't see a point
> > > in doing it ATM. The $subject patch allows rx-51 to be fully migrated to DM
> > > and does nothing different to what already is done all over the place.
> > 
> > So, there are deadlines for migration to device model.  The argument
> > being put forth by the Nokia RX51 folks is that to quote
> > include/dm/platdata.h (and yes, they aren't using U_BOOT_DRVINFO in this
> > case, but...):
> > /**
> >   * NOTE: Avoid using these except in extreme circumstances, where device tree
> >   * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
> >   * available). U-Boot's driver model uses device tree for configuration.
> >   *
> >   * When of-platdata is in use, U_BOOT_DRVINFO() cannot be used outside of the
> >   * dt-plat.c file created by dtoc
> >   */
> > that's them, and it's not an SPL case but full U-Boot and a fixed size
> > amount of the flash that they can use, no arguing.
> 
> As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> use SPL just like any other OMAP3 board.

U-Boot is being called by the old vendor X-Loader fork and needs to take
up the existing flash spot.

> > So we need to make
> > changes in subsystems they use so that they can continue to work.
> > 
> > So, are the changes being proposed to the generic USB code, such that
> > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > that's not set yet, but that's not to say never, it's just not been set,
> > so getting ahead of problems here would be appreciated) that can also be
> > enabled, OK?
> 
> I am confused by this reply. I noticed a lot of boards were removed over
> time because they were not converted to DM/DT, and to get rid of all the
> ifdefs, but now it seems the direction has been completely reversed and we
> should start adding back all the ifdefs to cater for boards which are not
> converted instead of fixing the boards ?

A lot of boards are being removed because no one wants to update and
maintain them and they have likely not been run-time tested in years.
Trying to clean up the code in those cases is best done by removing the
platform, as no one using it.   That is not the case here.  If your only
concern about the approach taken is some #ifdef's in the code, do you
want to see them converted to use some wrapper macro like we do in a few
other cases and __maybe_unused some functions as needed?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-20 15:54                   ` Tom Rini
@ 2021-06-20 19:43                     ` Marek Vasut
  2021-06-25 12:38                       ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2021-06-20 19:43 UTC (permalink / raw)
  To: Tom Rini
  Cc: Ivaylo Dimitrov, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

On 6/20/21 5:54 PM, Tom Rini wrote:

[...]

>> As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
>> use SPL just like any other OMAP3 board.
> 
> U-Boot is being called by the old vendor X-Loader fork and needs to take
> up the existing flash spot.

So, why not place SPL in those 256 kiB and load U-Boot proper from the 
eMMC ?

>>> So we need to make
>>> changes in subsystems they use so that they can continue to work.
>>>
>>> So, are the changes being proposed to the generic USB code, such that
>>> DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
>>> that's not set yet, but that's not to say never, it's just not been set,
>>> so getting ahead of problems here would be appreciated) that can also be
>>> enabled, OK?
>>
>> I am confused by this reply. I noticed a lot of boards were removed over
>> time because they were not converted to DM/DT, and to get rid of all the
>> ifdefs, but now it seems the direction has been completely reversed and we
>> should start adding back all the ifdefs to cater for boards which are not
>> converted instead of fixing the boards ?
> 
> A lot of boards are being removed because no one wants to update and
> maintain them and they have likely not been run-time tested in years.
> Trying to clean up the code in those cases is best done by removing the
> platform, as no one using it.   That is not the case here.

Note that there have been boards which had to be switched to SPL to even 
permit converting them to DM/DT, and thus prevent removal.

> If your only
> concern about the approach taken is some #ifdef's in the code, do you
> want to see them converted to use some wrapper macro like we do in a few
> other cases and __maybe_unused some functions as needed?

I think there is a better option which does not add any ifdefs at all 
_and_ is future-proof -- place SPL in those 256 kiB, load U-Boot from 
eMMC and then enable all the functionality you might need in U-Boot. 
That would free you from dealing with the size limitations basically 
indefinitely.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-20 19:43                     ` Marek Vasut
@ 2021-06-25 12:38                       ` Tom Rini
  2021-06-25 13:07                         ` Pali Rohár
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-25 12:38 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Ivaylo Dimitrov, Pali Rohár, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> On 6/20/21 5:54 PM, Tom Rini wrote:
> 
> [...]
> 
> > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > use SPL just like any other OMAP3 board.
> > 
> > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > up the existing flash spot.
> 
> So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> ?
> 
> > > > So we need to make
> > > > changes in subsystems they use so that they can continue to work.
> > > > 
> > > > So, are the changes being proposed to the generic USB code, such that
> > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > so getting ahead of problems here would be appreciated) that can also be
> > > > enabled, OK?
> > > 
> > > I am confused by this reply. I noticed a lot of boards were removed over
> > > time because they were not converted to DM/DT, and to get rid of all the
> > > ifdefs, but now it seems the direction has been completely reversed and we
> > > should start adding back all the ifdefs to cater for boards which are not
> > > converted instead of fixing the boards ?
> > 
> > A lot of boards are being removed because no one wants to update and
> > maintain them and they have likely not been run-time tested in years.
> > Trying to clean up the code in those cases is best done by removing the
> > platform, as no one using it.   That is not the case here.
> 
> Note that there have been boards which had to be switched to SPL to even
> permit converting them to DM/DT, and thus prevent removal.
> 
> > If your only
> > concern about the approach taken is some #ifdef's in the code, do you
> > want to see them converted to use some wrapper macro like we do in a few
> > other cases and __maybe_unused some functions as needed?
> 
> I think there is a better option which does not add any ifdefs at all _and_
> is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> then enable all the functionality you might need in U-Boot. That would free
> you from dealing with the size limitations basically indefinitely.

So, at this point I'm waiting for either of:
- A response to Marek's questions about using SPL, from the Nokia NX51
  folks.
- A patch to rework things so that USB gadget support more cleanly
  removes from the code paths non-gadget code, so there's no #if's being
  added here.  Or some similar clean-up.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 12:38                       ` Tom Rini
@ 2021-06-25 13:07                         ` Pali Rohár
  2021-06-25 16:04                           ` Simon Glass
  0 siblings, 1 reply; 36+ messages in thread
From: Pali Rohár @ 2021-06-25 13:07 UTC (permalink / raw)
  To: Tom Rini
  Cc: Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla, Simon Glass,
	Merlijn Wajer, u-boot, Pavel Machek

On Friday 25 June 2021 08:38:47 Tom Rini wrote:
> On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> > On 6/20/21 5:54 PM, Tom Rini wrote:
> > 
> > [...]
> > 
> > > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > > use SPL just like any other OMAP3 board.
> > > 
> > > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > > up the existing flash spot.
> > 
> > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> > ?
> > 
> > > > > So we need to make
> > > > > changes in subsystems they use so that they can continue to work.
> > > > > 
> > > > > So, are the changes being proposed to the generic USB code, such that
> > > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > > so getting ahead of problems here would be appreciated) that can also be
> > > > > enabled, OK?
> > > > 
> > > > I am confused by this reply. I noticed a lot of boards were removed over
> > > > time because they were not converted to DM/DT, and to get rid of all the
> > > > ifdefs, but now it seems the direction has been completely reversed and we
> > > > should start adding back all the ifdefs to cater for boards which are not
> > > > converted instead of fixing the boards ?
> > > 
> > > A lot of boards are being removed because no one wants to update and
> > > maintain them and they have likely not been run-time tested in years.
> > > Trying to clean up the code in those cases is best done by removing the
> > > platform, as no one using it.   That is not the case here.
> > 
> > Note that there have been boards which had to be switched to SPL to even
> > permit converting them to DM/DT, and thus prevent removal.
> > 
> > > If your only
> > > concern about the approach taken is some #ifdef's in the code, do you
> > > want to see them converted to use some wrapper macro like we do in a few
> > > other cases and __maybe_unused some functions as needed?
> > 
> > I think there is a better option which does not add any ifdefs at all _and_
> > is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> > then enable all the functionality you might need in U-Boot. That would free
> > you from dealing with the size limitations basically indefinitely.
> 
> So, at this point I'm waiting for either of:
> - A response to Marek's questions about using SPL, from the Nokia NX51
>   folks.

Hello Tom! Here is my answer:

> So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?

U-Boot for N900 does not use SPL. There is no SPL code implemented.
Nobody ever tried to implement it and neither tested. As you have
correctly pointed instead of SPL is used vendor X-Loader binary, which
is signed by RSA key.

Add eMMC: On eMMC is stored existing operating system, which somehow
also interacts with vendor X-Loader. There was no big investigation on
this topic. Also direct booting from eMMC is not supported (unless you
crack RSA, figure out how secure things work and generate compatible
image) and neither from existing X-Loader (because vendor did not
enabled it). There is no easy access to eMMC until you start full
U-Boot. So even if all these problems are solved then "bootstrapping" or
flashing U-Boot into such location is not possible, plus there is no
recovery. Plus this loose existing and working operating system, which
is no-go. So this way is basically undebugable and therefore perfectly
hard to develop.

Not mentioning that implementing this means to implement all N900 code
in U-Boot from scratch. And the last thing is testing...

For me this idea looks like total perfectionism in corporate world when
some software architect invent a new super-duper-über solution for
everything which in reality is not possible to implement.

PS: In past few people investigated topic on cracking RSA signature on
Omap3 and nobody was able to find any "security issue" in it...

> - A patch to rework things so that USB gadget support more cleanly
>   removes from the code paths non-gadget code, so there's no #if's being
>   added here.  Or some similar clean-up.
> 
> -- 
> Tom



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 13:07                         ` Pali Rohár
@ 2021-06-25 16:04                           ` Simon Glass
  2021-06-25 16:16                             ` Pali Rohár
  2021-06-25 21:31                             ` Ivaylo Dimitrov
  0 siblings, 2 replies; 36+ messages in thread
From: Simon Glass @ 2021-06-25 16:04 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Tom Rini, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

Hi Pali,

On Fri, 25 Jun 2021 at 07:07, Pali Rohár <pali@kernel.org> wrote:
>
> On Friday 25 June 2021 08:38:47 Tom Rini wrote:
> > On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> > > On 6/20/21 5:54 PM, Tom Rini wrote:
> > >
> > > [...]
> > >
> > > > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > > > use SPL just like any other OMAP3 board.
> > > >
> > > > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > > > up the existing flash spot.
> > >
> > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> > > ?
> > >
> > > > > > So we need to make
> > > > > > changes in subsystems they use so that they can continue to work.
> > > > > >
> > > > > > So, are the changes being proposed to the generic USB code, such that
> > > > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > > > so getting ahead of problems here would be appreciated) that can also be
> > > > > > enabled, OK?
> > > > >
> > > > > I am confused by this reply. I noticed a lot of boards were removed over
> > > > > time because they were not converted to DM/DT, and to get rid of all the
> > > > > ifdefs, but now it seems the direction has been completely reversed and we
> > > > > should start adding back all the ifdefs to cater for boards which are not
> > > > > converted instead of fixing the boards ?
> > > >
> > > > A lot of boards are being removed because no one wants to update and
> > > > maintain them and they have likely not been run-time tested in years.
> > > > Trying to clean up the code in those cases is best done by removing the
> > > > platform, as no one using it.   That is not the case here.
> > >
> > > Note that there have been boards which had to be switched to SPL to even
> > > permit converting them to DM/DT, and thus prevent removal.
> > >
> > > > If your only
> > > > concern about the approach taken is some #ifdef's in the code, do you
> > > > want to see them converted to use some wrapper macro like we do in a few
> > > > other cases and __maybe_unused some functions as needed?
> > >
> > > I think there is a better option which does not add any ifdefs at all _and_
> > > is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> > > then enable all the functionality you might need in U-Boot. That would free
> > > you from dealing with the size limitations basically indefinitely.
> >
> > So, at this point I'm waiting for either of:
> > - A response to Marek's questions about using SPL, from the Nokia NX51
> >   folks.
>
> Hello Tom! Here is my answer:
>
> > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?
>
> U-Boot for N900 does not use SPL. There is no SPL code implemented.
> Nobody ever tried to implement it and neither tested. As you have
> correctly pointed instead of SPL is used vendor X-Loader binary, which
> is signed by RSA key.
>
> Add eMMC: On eMMC is stored existing operating system, which somehow
> also interacts with vendor X-Loader. There was no big investigation on
> this topic. Also direct booting from eMMC is not supported (unless you
> crack RSA, figure out how secure things work and generate compatible
> image) and neither from existing X-Loader (because vendor did not
> enabled it). There is no easy access to eMMC until you start full
> U-Boot. So even if all these problems are solved then "bootstrapping" or
> flashing U-Boot into such location is not possible, plus there is no
> recovery. Plus this loose existing and working operating system, which
> is no-go. So this way is basically undebugable and therefore perfectly
> hard to develop.

I don't want to inject myself in this discussion, although it does
sound like this platform should use SPL. But I do wonder about the
100KB growth you saw with DT/DM. That seems absolutely enormous to me!
Can you please point me to the git tree for this? I'd like to
investigate.

- Simon

>
> Not mentioning that implementing this means to implement all N900 code
> in U-Boot from scratch. And the last thing is testing...
>
> For me this idea looks like total perfectionism in corporate world when
> some software architect invent a new super-duper-über solution for
> everything which in reality is not possible to implement.
>
> PS: In past few people investigated topic on cracking RSA signature on
> Omap3 and nobody was able to find any "security issue" in it...
>
> > - A patch to rework things so that USB gadget support more cleanly
> >   removes from the code paths non-gadget code, so there's no #if's being
> >   added here.  Or some similar clean-up.
> >
> > --
> > Tom
>
>

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 16:04                           ` Simon Glass
@ 2021-06-25 16:16                             ` Pali Rohár
  2021-06-25 16:43                               ` Simon Glass
  2021-06-25 21:31                             ` Ivaylo Dimitrov
  1 sibling, 1 reply; 36+ messages in thread
From: Pali Rohár @ 2021-06-25 16:16 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> Hi Pali,
> 
> On Fri, 25 Jun 2021 at 07:07, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Friday 25 June 2021 08:38:47 Tom Rini wrote:
> > > On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> > > > On 6/20/21 5:54 PM, Tom Rini wrote:
> > > >
> > > > [...]
> > > >
> > > > > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > > > > use SPL just like any other OMAP3 board.
> > > > >
> > > > > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > > > > up the existing flash spot.
> > > >
> > > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> > > > ?
> > > >
> > > > > > > So we need to make
> > > > > > > changes in subsystems they use so that they can continue to work.
> > > > > > >
> > > > > > > So, are the changes being proposed to the generic USB code, such that
> > > > > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > > > > so getting ahead of problems here would be appreciated) that can also be
> > > > > > > enabled, OK?
> > > > > >
> > > > > > I am confused by this reply. I noticed a lot of boards were removed over
> > > > > > time because they were not converted to DM/DT, and to get rid of all the
> > > > > > ifdefs, but now it seems the direction has been completely reversed and we
> > > > > > should start adding back all the ifdefs to cater for boards which are not
> > > > > > converted instead of fixing the boards ?
> > > > >
> > > > > A lot of boards are being removed because no one wants to update and
> > > > > maintain them and they have likely not been run-time tested in years.
> > > > > Trying to clean up the code in those cases is best done by removing the
> > > > > platform, as no one using it.   That is not the case here.
> > > >
> > > > Note that there have been boards which had to be switched to SPL to even
> > > > permit converting them to DM/DT, and thus prevent removal.
> > > >
> > > > > If your only
> > > > > concern about the approach taken is some #ifdef's in the code, do you
> > > > > want to see them converted to use some wrapper macro like we do in a few
> > > > > other cases and __maybe_unused some functions as needed?
> > > >
> > > > I think there is a better option which does not add any ifdefs at all _and_
> > > > is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> > > > then enable all the functionality you might need in U-Boot. That would free
> > > > you from dealing with the size limitations basically indefinitely.
> > >
> > > So, at this point I'm waiting for either of:
> > > - A response to Marek's questions about using SPL, from the Nokia NX51
> > >   folks.
> >
> > Hello Tom! Here is my answer:
> >
> > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?
> >
> > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > Nobody ever tried to implement it and neither tested. As you have
> > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > is signed by RSA key.
> >
> > Add eMMC: On eMMC is stored existing operating system, which somehow
> > also interacts with vendor X-Loader. There was no big investigation on
> > this topic. Also direct booting from eMMC is not supported (unless you
> > crack RSA, figure out how secure things work and generate compatible
> > image) and neither from existing X-Loader (because vendor did not
> > enabled it). There is no easy access to eMMC until you start full
> > U-Boot. So even if all these problems are solved then "bootstrapping" or
> > flashing U-Boot into such location is not possible, plus there is no
> > recovery. Plus this loose existing and working operating system, which
> > is no-go. So this way is basically undebugable and therefore perfectly
> > hard to develop.
> 
> I don't want to inject myself in this discussion, although it does
> sound like this platform should use SPL.

Well, we are using TI/Nokia X-Loader, not SPL due to above reasons. Like
it was for all other TI Omap3/4 boards in past (I guess now TI X-Loader
is being replaced by U-Boot SPL part).

> But I do wonder about the
> 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> Can you please point me to the git tree for this? I'd like to
> investigate.

Patches in this series were written by Ivo. I do not know exact details
and numbers. But the fact is that it was required to enable thumb-2 mode
(which has hw bugs on this cpu, see earlier emails; reason why it was
disabled). If you want to investigate it, you can try compare u-boot
from master/next and u-boot with applying these patches + disable
thumb-2 mode. Note that we have already enabled LTO.

> 
> - Simon
> 
> >
> > Not mentioning that implementing this means to implement all N900 code
> > in U-Boot from scratch. And the last thing is testing...
> >
> > For me this idea looks like total perfectionism in corporate world when
> > some software architect invent a new super-duper-über solution for
> > everything which in reality is not possible to implement.
> >
> > PS: In past few people investigated topic on cracking RSA signature on
> > Omap3 and nobody was able to find any "security issue" in it...
> >
> > > - A patch to rework things so that USB gadget support more cleanly
> > >   removes from the code paths non-gadget code, so there's no #if's being
> > >   added here.  Or some similar clean-up.
> > >
> > > --
> > > Tom
> >
> >

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 16:16                             ` Pali Rohár
@ 2021-06-25 16:43                               ` Simon Glass
  2021-06-25 16:58                                 ` Pali Rohár
  0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2021-06-25 16:43 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Tom Rini, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

Hi Pali,

On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
>
> On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > Hi Pali,
> >
> > On Fri, 25 Jun 2021 at 07:07, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Friday 25 June 2021 08:38:47 Tom Rini wrote:
> > > > On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> > > > > On 6/20/21 5:54 PM, Tom Rini wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > > > > > use SPL just like any other OMAP3 board.
> > > > > >
> > > > > > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > > > > > up the existing flash spot.
> > > > >
> > > > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> > > > > ?
> > > > >
> > > > > > > > So we need to make
> > > > > > > > changes in subsystems they use so that they can continue to work.
> > > > > > > >
> > > > > > > > So, are the changes being proposed to the generic USB code, such that
> > > > > > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > > > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > > > > > so getting ahead of problems here would be appreciated) that can also be
> > > > > > > > enabled, OK?
> > > > > > >
> > > > > > > I am confused by this reply. I noticed a lot of boards were removed over
> > > > > > > time because they were not converted to DM/DT, and to get rid of all the
> > > > > > > ifdefs, but now it seems the direction has been completely reversed and we
> > > > > > > should start adding back all the ifdefs to cater for boards which are not
> > > > > > > converted instead of fixing the boards ?
> > > > > >
> > > > > > A lot of boards are being removed because no one wants to update and
> > > > > > maintain them and they have likely not been run-time tested in years.
> > > > > > Trying to clean up the code in those cases is best done by removing the
> > > > > > platform, as no one using it.   That is not the case here.
> > > > >
> > > > > Note that there have been boards which had to be switched to SPL to even
> > > > > permit converting them to DM/DT, and thus prevent removal.
> > > > >
> > > > > > If your only
> > > > > > concern about the approach taken is some #ifdef's in the code, do you
> > > > > > want to see them converted to use some wrapper macro like we do in a few
> > > > > > other cases and __maybe_unused some functions as needed?
> > > > >
> > > > > I think there is a better option which does not add any ifdefs at all _and_
> > > > > is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> > > > > then enable all the functionality you might need in U-Boot. That would free
> > > > > you from dealing with the size limitations basically indefinitely.
> > > >
> > > > So, at this point I'm waiting for either of:
> > > > - A response to Marek's questions about using SPL, from the Nokia NX51
> > > >   folks.
> > >
> > > Hello Tom! Here is my answer:
> > >
> > > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?
> > >
> > > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > > Nobody ever tried to implement it and neither tested. As you have
> > > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > > is signed by RSA key.
> > >
> > > Add eMMC: On eMMC is stored existing operating system, which somehow
> > > also interacts with vendor X-Loader. There was no big investigation on
> > > this topic. Also direct booting from eMMC is not supported (unless you
> > > crack RSA, figure out how secure things work and generate compatible
> > > image) and neither from existing X-Loader (because vendor did not
> > > enabled it). There is no easy access to eMMC until you start full
> > > U-Boot. So even if all these problems are solved then "bootstrapping" or
> > > flashing U-Boot into such location is not possible, plus there is no
> > > recovery. Plus this loose existing and working operating system, which
> > > is no-go. So this way is basically undebugable and therefore perfectly
> > > hard to develop.
> >
> > I don't want to inject myself in this discussion, although it does
> > sound like this platform should use SPL.
>
> Well, we are using TI/Nokia X-Loader, not SPL due to above reasons. Like
> it was for all other TI Omap3/4 boards in past (I guess now TI X-Loader
> is being replaced by U-Boot SPL part).
>
> > But I do wonder about the
> > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > Can you please point me to the git tree for this? I'd like to
> > investigate.
>
> Patches in this series were written by Ivo. I do not know exact details
> and numbers. But the fact is that it was required to enable thumb-2 mode
> (which has hw bugs on this cpu, see earlier emails; reason why it was
> disabled). If you want to investigate it, you can try compare u-boot
> from master/next and u-boot with applying these patches + disable
> thumb-2 mode. Note that we have already enabled LTO.
>

That's probably a little beyond my level of enthusiasm. But if you are
able to push a tree with before/after commits, I will take a look.

Regards,
SImon

> >
> > - Simon
> >
> > >
> > > Not mentioning that implementing this means to implement all N900 code
> > > in U-Boot from scratch. And the last thing is testing...
> > >
> > > For me this idea looks like total perfectionism in corporate world when
> > > some software architect invent a new super-duper-über solution for
> > > everything which in reality is not possible to implement.
> > >
> > > PS: In past few people investigated topic on cracking RSA signature on
> > > Omap3 and nobody was able to find any "security issue" in it...
> > >
> > > > - A patch to rework things so that USB gadget support more cleanly
> > > >   removes from the code paths non-gadget code, so there's no #if's being
> > > >   added here.  Or some similar clean-up.
> > > >
> > > > --
> > > > Tom
> > >
> > >

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 16:43                               ` Simon Glass
@ 2021-06-25 16:58                                 ` Pali Rohár
  2021-06-27 19:06                                   ` Simon Glass
  0 siblings, 1 reply; 36+ messages in thread
From: Pali Rohár @ 2021-06-25 16:58 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

On Friday 25 June 2021 10:43:11 Simon Glass wrote:
> Hi Pali,
> 
> On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > > But I do wonder about the
> > > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > > Can you please point me to the git tree for this? I'd like to
> > > investigate.
> >
> > Patches in this series were written by Ivo. I do not know exact details
> > and numbers. But the fact is that it was required to enable thumb-2 mode
> > (which has hw bugs on this cpu, see earlier emails; reason why it was
> > disabled). If you want to investigate it, you can try compare u-boot
> > from master/next and u-boot with applying these patches + disable
> > thumb-2 mode. Note that we have already enabled LTO.
> >
> 
> That's probably a little beyond my level of enthusiasm. But if you are
> able to push a tree with before/after commits, I will take a look.

Hello Simon! I have already pushed these patches to github due to CI
testing. So you can easily access them via git fetch/checkout.

Before (this is already in u-boot git):
$ git checkout a298d4fbcdba1b38e48ea2af0fc5386cab2070da

After1:
$ git fetch https://github.com/u-boot/u-boot.git refs/pull/83/head
$ git checkout 1f038c8b45ef0018e52a2a4587eb73170769ac2f

After2:
= use After1 with:
  + disable CONFIG_SYS_THUMB_BUILD
  + enable CONFIG_OF_LIBFDT_OVERLAY
  + enable CONFIG_CMD_FDT

defconfig file is nokia_rx51_defconfig

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 16:04                           ` Simon Glass
  2021-06-25 16:16                             ` Pali Rohár
@ 2021-06-25 21:31                             ` Ivaylo Dimitrov
  2021-06-25 21:37                               ` Tom Rini
  1 sibling, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-25 21:31 UTC (permalink / raw)
  To: Simon Glass, Pali Rohár
  Cc: Tom Rini, Marek Vasut, Lokesh Vutla, Merlijn Wajer,
	U-Boot Mailing List, Pavel Machek


On 25.06.21 г. 19:04 ч., Simon Glass wrote:
> Hi Pali,
>
> On Fri, 25 Jun 2021 at 07:07, Pali Rohár <pali@kernel.org> wrote:
>> On Friday 25 June 2021 08:38:47 Tom Rini wrote:
>>> On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
>>>> On 6/20/21 5:54 PM, Tom Rini wrote:
>>>>
>>>> [...]
>>>>
>>>>>> As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
>>>>>> use SPL just like any other OMAP3 board.
>>>>> U-Boot is being called by the old vendor X-Loader fork and needs to take
>>>>> up the existing flash spot.
>>>> So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
>>>> ?
>>>>
>>>>>>> So we need to make
>>>>>>> changes in subsystems they use so that they can continue to work.
>>>>>>>
>>>>>>> So, are the changes being proposed to the generic USB code, such that
>>>>>>> DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
>>>>>>> that's not set yet, but that's not to say never, it's just not been set,
>>>>>>> so getting ahead of problems here would be appreciated) that can also be
>>>>>>> enabled, OK?
>>>>>> I am confused by this reply. I noticed a lot of boards were removed over
>>>>>> time because they were not converted to DM/DT, and to get rid of all the
>>>>>> ifdefs, but now it seems the direction has been completely reversed and we
>>>>>> should start adding back all the ifdefs to cater for boards which are not
>>>>>> converted instead of fixing the boards ?
>>>>> A lot of boards are being removed because no one wants to update and
>>>>> maintain them and they have likely not been run-time tested in years.
>>>>> Trying to clean up the code in those cases is best done by removing the
>>>>> platform, as no one using it.   That is not the case here.
>>>> Note that there have been boards which had to be switched to SPL to even
>>>> permit converting them to DM/DT, and thus prevent removal.
>>>>
>>>>> If your only
>>>>> concern about the approach taken is some #ifdef's in the code, do you
>>>>> want to see them converted to use some wrapper macro like we do in a few
>>>>> other cases and __maybe_unused some functions as needed?
>>>> I think there is a better option which does not add any ifdefs at all _and_
>>>> is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
>>>> then enable all the functionality you might need in U-Boot. That would free
>>>> you from dealing with the size limitations basically indefinitely.
>>> So, at this point I'm waiting for either of:
>>> - A response to Marek's questions about using SPL, from the Nokia NX51
>>>    folks.
>> Hello Tom! Here is my answer:
>>
>>> So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?
>> U-Boot for N900 does not use SPL. There is no SPL code implemented.
>> Nobody ever tried to implement it and neither tested. As you have
>> correctly pointed instead of SPL is used vendor X-Loader binary, which
>> is signed by RSA key.
>>
>> Add eMMC: On eMMC is stored existing operating system, which somehow
>> also interacts with vendor X-Loader. There was no big investigation on
>> this topic. Also direct booting from eMMC is not supported (unless you
>> crack RSA, figure out how secure things work and generate compatible
>> image) and neither from existing X-Loader (because vendor did not
>> enabled it). There is no easy access to eMMC until you start full
>> U-Boot. So even if all these problems are solved then "bootstrapping" or
>> flashing U-Boot into such location is not possible, plus there is no
>> recovery. Plus this loose existing and working operating system, which
>> is no-go. So this way is basically undebugable and therefore perfectly
>> hard to develop.
> I don't want to inject myself in this discussion, although it does
> sound like this platform should use SPL. But I do wonder about the
> 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> Can you please point me to the git tree for this? I'd like to
> investigate.


It seems OF_CONTROL pulls everything and the kitchen sink (stuff like 
EFI loader support, for example). I am on holiday ATM with limited 
access to my home PC (slow internet), however, one can easily recreate 
the issue on the current master by just adding CONFIG_OF_CONTROL=y to 
N900 defconfig. Build will fail (no DTS), but no_dts binary built is 
well above 350kB vs ~240kB without .


In regards to SPL - there is no way to sign SPL with the keys used by 
Nokia to sign NOLO(the proprietary second stage loader), we simply don't 
have them. Without that, we can't replace NOLO.


Ivo

> - Simon
>
>> Not mentioning that implementing this means to implement all N900 code
>> in U-Boot from scratch. And the last thing is testing...
>>
>> For me this idea looks like total perfectionism in corporate world when
>> some software architect invent a new super-duper-über solution for
>> everything which in reality is not possible to implement.
>>
>> PS: In past few people investigated topic on cracking RSA signature on
>> Omap3 and nobody was able to find any "security issue" in it...
>>
>>> - A patch to rework things so that USB gadget support more cleanly
>>>    removes from the code paths non-gadget code, so there's no #if's being
>>>    added here.  Or some similar clean-up.
>>>
>>> --
>>> Tom
>>

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 21:31                             ` Ivaylo Dimitrov
@ 2021-06-25 21:37                               ` Tom Rini
  2021-06-25 21:51                                 ` Pali Rohár
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-25 21:37 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Simon Glass, Pali Rohár, Marek Vasut, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Sat, Jun 26, 2021 at 12:31:49AM +0300, Ivaylo Dimitrov wrote:

[snip]
> In regards to SPL - there is no way to sign SPL with the keys used by Nokia
> to sign NOLO(the proprietary second stage loader), we simply don't have
> them. Without that, we can't replace NOLO.

One thing I want to say here as I think it maybe wasn't clear in Marek's
suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
on the eMMC?  Yes, you would still want to turn off EFI_LOADER (and
possibly GENERATE_SMBIOS_TABLE) but that would also largely remove the
specific size requirement here.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 21:37                               ` Tom Rini
@ 2021-06-25 21:51                                 ` Pali Rohár
  2021-06-25 21:59                                   ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Pali Rohár @ 2021-06-25 21:51 UTC (permalink / raw)
  To: Tom Rini
  Cc: Ivaylo Dimitrov, Simon Glass, Marek Vasut, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> One thing I want to say here as I think it maybe wasn't clear in Marek's
> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> on the eMMC?

Hello Tom! I have already answered this in my previous email.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 21:51                                 ` Pali Rohár
@ 2021-06-25 21:59                                   ` Tom Rini
  2021-06-26 10:59                                     ` Merlijn Wajer
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-25 21:59 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Ivaylo Dimitrov, Simon Glass, Marek Vasut, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> > One thing I want to say here as I think it maybe wasn't clear in Marek's
> > suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> > on the eMMC?
> 
> Hello Tom! I have already answered this in my previous email.

I just re-read things and I don't see it.  But perhaps I'm not being
clear enough.  Why can't you just have NOLO start SPL, not re-initialize
things (which is a really common case now thanks to aarch64) and just
use that to load full U-Boot from a not size restricted place?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 21:59                                   ` Tom Rini
@ 2021-06-26 10:59                                     ` Merlijn Wajer
  2021-06-26 14:58                                       ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Merlijn Wajer @ 2021-06-26 10:59 UTC (permalink / raw)
  To: Tom Rini, Pali Rohár
  Cc: Ivaylo Dimitrov, Simon Glass, Marek Vasut, Lokesh Vutla,
	U-Boot Mailing List, Pavel Machek

Hi Tom, Marek,

On 25/06/2021 23:59, Tom Rini wrote:
> On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
>> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
>>> One thing I want to say here as I think it maybe wasn't clear in Marek's
>>> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
>>> on the eMMC?
>>
>> Hello Tom! I have already answered this in my previous email.
> 
> I just re-read things and I don't see it.  But perhaps I'm not being
> clear enough.  Why can't you just have NOLO start SPL, not re-initialize
> things (which is a really common case now thanks to aarch64) and just
> use that to load full U-Boot from a not size restricted place?
> 

I think there are a few problems.

1. One is a practical one, from Pali's email:

> There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.

Not being able to access the eMMC to write u-boot until u-boot is
started does sound like it would make things a bit more tricky.

2. According to Pali, adding SPL support would not be a trivial task,
and might end up with a lot more "#ifdef"s in SPL than the one in
Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
not do any hardware initialisation on the N900, so that might be where
instead hacks would need to be added to SPL.

Pali also wrote:

> U-Boot for N900 does not use SPL. There is no SPL code implemented.
> Nobody ever tried to implement it and neither tested. As you have
> correctly pointed instead of SPL is used vendor X-Loader binary, which
> is signed by RSA key.
And when I asked him today:

> 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
> 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
> 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
So perhaps it would make sense to get more clarity on that, since that
seems to be where the argument gets stuck.


Also, I'd like to point what Ivaylo wrote earlier:

>> This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
> 
> Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
> 
> Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.

If the other drivers have the same logic, it seems a bit weird to me
that the change made in Ivaylo's patch would be rejected because of a
preference to port the board to DT. Unless maybe this was the first
driver to be migrated to support only DT and the patch is in effect a
reversal of some prior work?

Of course, in the long run all boards should follow u-boot technological
preferences, but it feels a bit off that this patch would be treated
differently if the existing drivers already use the same logic, and as
far as I can see there is no deadline currently to convert boards to DT,
just for converting them to DM.

Regards,
Merlijn

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-26 10:59                                     ` Merlijn Wajer
@ 2021-06-26 14:58                                       ` Tom Rini
  2021-06-30  7:12                                         ` Ivaylo Dimitrov
  2021-06-30  7:30                                         ` Ivaylo Dimitrov
  0 siblings, 2 replies; 36+ messages in thread
From: Tom Rini @ 2021-06-26 14:58 UTC (permalink / raw)
  To: Merlijn Wajer
  Cc: Pali Rohár, Ivaylo Dimitrov, Simon Glass, Marek Vasut,
	Lokesh Vutla, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]

On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
> Hi Tom, Marek,
> 
> On 25/06/2021 23:59, Tom Rini wrote:
> > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
> >> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> >>> One thing I want to say here as I think it maybe wasn't clear in Marek's
> >>> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> >>> on the eMMC?
> >>
> >> Hello Tom! I have already answered this in my previous email.
> > 
> > I just re-read things and I don't see it.  But perhaps I'm not being
> > clear enough.  Why can't you just have NOLO start SPL, not re-initialize
> > things (which is a really common case now thanks to aarch64) and just
> > use that to load full U-Boot from a not size restricted place?
> > 
> 
> I think there are a few problems.
> 
> 1. One is a practical one, from Pali's email:
> 
> > There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
> 
> Not being able to access the eMMC to write u-boot until u-boot is
> started does sound like it would make things a bit more tricky.

I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.

> 2. According to Pali, adding SPL support would not be a trivial task,
> and might end up with a lot more "#ifdef"s in SPL than the one in
> Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
> not do any hardware initialisation on the N900, so that might be where
> instead hacks would need to be added to SPL.
> 
> Pali also wrote:
> 
> > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > Nobody ever tried to implement it and neither tested. As you have
> > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > is signed by RSA key.
> And when I asked him today:
> 
> > 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
> > 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
> > 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
> So perhaps it would make sense to get more clarity on that, since that
> seems to be where the argument gets stuck.

This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
let you skip whatever initialization doesn't need to be done.  If
there's some init that needs to be skipped but isn't, that's a bug.

> Also, I'd like to point what Ivaylo wrote earlier:
> 
> >> This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
> > 
> > Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
> > 
> > Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
> 
> If the other drivers have the same logic, it seems a bit weird to me
> that the change made in Ivaylo's patch would be rejected because of a
> preference to port the board to DT. Unless maybe this was the first
> driver to be migrated to support only DT and the patch is in effect a
> reversal of some prior work?

Yes, part of the problem here is that DM_USB is the first case that N900
has hit as part of DM conversion that written with using OF_CONTROL in
mind, only.  And he's not interested in taking workarounds to provide
the required information via another mechanism (while i2c for example,
is).

But another one of the problems here is that N900 doesn't need USB host,
only USB gadget, and you were disabling some of the host stuff that's
being built but not used.  A change to not include unused host mode code
entirely would be another path, and you can address moving to
DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
and see if you have to re-visit the OF_CONTROL problem or not.

> Of course, in the long run all boards should follow u-boot technological
> preferences, but it feels a bit off that this patch would be treated
> differently if the existing drivers already use the same logic, and as
> far as I can see there is no deadline currently to convert boards to DT,
> just for converting them to DM.

The deadline in question here is USB.  It's going on 2 years past due
and 3 years since the warning was added.  So that we're talking just now
about the problem, since I started off by just removing the platform,
isn't great.  And it's not being treated differently, there's no
U_BOOT_DRVINFOS option for USB, which is where those other #ifdef's are
related to, I believe.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning
  2021-06-18 14:57 ` [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning Pali Rohár
@ 2021-06-26 18:31   ` Simon Glass
  0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2021-06-26 18:31 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Lokesh Vutla, Tom Rini, Ivaylo Dimitrov, Merlijn Wajer,
	maemo-leste, U-Boot Mailing List, Pavel Machek

On Fri, 18 Jun 2021 at 08:57, Pali Rohár <pali@kernel.org> wrote:
>
> From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>
> Also disable various options that are auto-enabled by default, but not
> really applicable to RX-51.
>
> Enable CONFIG_SYS_THUMB_BUILD, otherwise the resulting binary becomes too
> large to be useful on a real hardware.
>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Tested-by: Pali Rohár <pali@kernel.org>
> ---
>  configs/nokia_rx51_defconfig | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-25 16:58                                 ` Pali Rohár
@ 2021-06-27 19:06                                   ` Simon Glass
  2021-06-28 13:39                                     ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2021-06-27 19:06 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Tom Rini, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

Hi Pali,

On Fri, 25 Jun 2021 at 10:58, Pali Rohár <pali@kernel.org> wrote:
>
> On Friday 25 June 2021 10:43:11 Simon Glass wrote:
> > Hi Pali,
> >
> > On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > > > But I do wonder about the
> > > > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > > > Can you please point me to the git tree for this? I'd like to
> > > > investigate.
> > >
> > > Patches in this series were written by Ivo. I do not know exact details
> > > and numbers. But the fact is that it was required to enable thumb-2 mode
> > > (which has hw bugs on this cpu, see earlier emails; reason why it was
> > > disabled). If you want to investigate it, you can try compare u-boot
> > > from master/next and u-boot with applying these patches + disable
> > > thumb-2 mode. Note that we have already enabled LTO.
> > >
> >
> > That's probably a little beyond my level of enthusiasm. But if you are
> > able to push a tree with before/after commits, I will take a look.
>
> Hello Simon! I have already pushed these patches to github due to CI
> testing. So you can easily access them via git fetch/checkout.
>
> Before (this is already in u-boot git):
> $ git checkout a298d4fbcdba1b38e48ea2af0fc5386cab2070da
>
> After1:
> $ git fetch https://github.com/u-boot/u-boot.git refs/pull/83/head
> $ git checkout 1f038c8b45ef0018e52a2a4587eb73170769ac2f
>
> After2:
> = use After1 with:
>   + disable CONFIG_SYS_THUMB_BUILD
>   + enable CONFIG_OF_LIBFDT_OVERLAY
>   + enable CONFIG_CMD_FDT
>
> defconfig file is nokia_rx51_defconfig

OK thanks, I see it. I pushed a tree to u-boot-dm/nokia_rx51 with a
few changes. The growth is about 19KB (without enabling Thumb). Some
more fine-grained control of what get enabled with LIBFDT could be
added to reduce that, perhaps by 5KB.

It has made me realise what a lot of bloat EBBR adds. I'll send a
patch to disable it by default.

Regards,
Simon

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-27 19:06                                   ` Simon Glass
@ 2021-06-28 13:39                                     ` Tom Rini
  2021-06-28 14:20                                       ` Simon Glass
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-28 13:39 UTC (permalink / raw)
  To: Simon Glass
  Cc: Pali Rohár, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

On Sun, Jun 27, 2021 at 01:06:12PM -0600, Simon Glass wrote:
> Hi Pali,
> 
> On Fri, 25 Jun 2021 at 10:58, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Friday 25 June 2021 10:43:11 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > > > > But I do wonder about the
> > > > > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > > > > Can you please point me to the git tree for this? I'd like to
> > > > > investigate.
> > > >
> > > > Patches in this series were written by Ivo. I do not know exact details
> > > > and numbers. But the fact is that it was required to enable thumb-2 mode
> > > > (which has hw bugs on this cpu, see earlier emails; reason why it was
> > > > disabled). If you want to investigate it, you can try compare u-boot
> > > > from master/next and u-boot with applying these patches + disable
> > > > thumb-2 mode. Note that we have already enabled LTO.
> > > >
> > >
> > > That's probably a little beyond my level of enthusiasm. But if you are
> > > able to push a tree with before/after commits, I will take a look.
> >
> > Hello Simon! I have already pushed these patches to github due to CI
> > testing. So you can easily access them via git fetch/checkout.
> >
> > Before (this is already in u-boot git):
> > $ git checkout a298d4fbcdba1b38e48ea2af0fc5386cab2070da
> >
> > After1:
> > $ git fetch https://github.com/u-boot/u-boot.git refs/pull/83/head
> > $ git checkout 1f038c8b45ef0018e52a2a4587eb73170769ac2f
> >
> > After2:
> > = use After1 with:
> >   + disable CONFIG_SYS_THUMB_BUILD
> >   + enable CONFIG_OF_LIBFDT_OVERLAY
> >   + enable CONFIG_CMD_FDT
> >
> > defconfig file is nokia_rx51_defconfig
> 
> OK thanks, I see it. I pushed a tree to u-boot-dm/nokia_rx51 with a
> few changes. The growth is about 19KB (without enabling Thumb). Some
> more fine-grained control of what get enabled with LIBFDT could be
> added to reduce that, perhaps by 5KB.

So, was the entirety of the reduction you saw from dropping out
EFI_LOADER?  Just most of it?  Disabling that came up in another part of
this thread.  And if we just need to disable EFI_LOADER,
OF_LIBFDT_OVERLAY and CMD_FDT (and maybe tweak the mask value) in order
to not need to do any other changes, yes, that's the right approach.  It
would be helpful, but not required, to confirm if thumb works or fails
on hardware, but I do understand it's a PITA to unbrick these devices.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-28 13:39                                     ` Tom Rini
@ 2021-06-28 14:20                                       ` Simon Glass
  2021-06-28 14:43                                         ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2021-06-28 14:20 UTC (permalink / raw)
  To: Tom Rini
  Cc: Pali Rohár, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

Hi Tom,

On Mon, 28 Jun 2021 at 07:39, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jun 27, 2021 at 01:06:12PM -0600, Simon Glass wrote:
> > Hi Pali,
> >
> > On Fri, 25 Jun 2021 at 10:58, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Friday 25 June 2021 10:43:11 Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > > > > > But I do wonder about the
> > > > > > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > > > > > Can you please point me to the git tree for this? I'd like to
> > > > > > investigate.
> > > > >
> > > > > Patches in this series were written by Ivo. I do not know exact details
> > > > > and numbers. But the fact is that it was required to enable thumb-2 mode
> > > > > (which has hw bugs on this cpu, see earlier emails; reason why it was
> > > > > disabled). If you want to investigate it, you can try compare u-boot
> > > > > from master/next and u-boot with applying these patches + disable
> > > > > thumb-2 mode. Note that we have already enabled LTO.
> > > > >
> > > >
> > > > That's probably a little beyond my level of enthusiasm. But if you are
> > > > able to push a tree with before/after commits, I will take a look.
> > >
> > > Hello Simon! I have already pushed these patches to github due to CI
> > > testing. So you can easily access them via git fetch/checkout.
> > >
> > > Before (this is already in u-boot git):
> > > $ git checkout a298d4fbcdba1b38e48ea2af0fc5386cab2070da
> > >
> > > After1:
> > > $ git fetch https://github.com/u-boot/u-boot.git refs/pull/83/head
> > > $ git checkout 1f038c8b45ef0018e52a2a4587eb73170769ac2f
> > >
> > > After2:
> > > = use After1 with:
> > >   + disable CONFIG_SYS_THUMB_BUILD
> > >   + enable CONFIG_OF_LIBFDT_OVERLAY
> > >   + enable CONFIG_CMD_FDT
> > >
> > > defconfig file is nokia_rx51_defconfig
> >
> > OK thanks, I see it. I pushed a tree to u-boot-dm/nokia_rx51 with a
> > few changes. The growth is about 19KB (without enabling Thumb). Some
> > more fine-grained control of what get enabled with LIBFDT could be
> > added to reduce that, perhaps by 5KB.
>
> So, was the entirety of the reduction you saw from dropping out
> EFI_LOADER?  Just most of it?  Disabling that came up in another part of
> this thread.  And if we just need to disable EFI_LOADER,
> OF_LIBFDT_OVERLAY and CMD_FDT (and maybe tweak the mask value) in order
> to not need to do any other changes, yes, that's the right approach.  It

For me, it dropped the size by about 90KB, although I'm including
text, rodata and data in that number:

default
        arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0
rodata +10989.0 text +109846.0

without ebbr
       arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0
rodata +5333.0 text +29712.0

> would be helpful, but not required, to confirm if thumb works or fails
> on hardware, but I do understand it's a PITA to unbrick these devices.

Regards,
Simon

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-28 14:20                                       ` Simon Glass
@ 2021-06-28 14:43                                         ` Tom Rini
  0 siblings, 0 replies; 36+ messages in thread
From: Tom Rini @ 2021-06-28 14:43 UTC (permalink / raw)
  To: Simon Glass
  Cc: Pali Rohár, Marek Vasut, Ivaylo Dimitrov, Lokesh Vutla,
	Merlijn Wajer, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]

On Mon, Jun 28, 2021 at 08:20:31AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 28 Jun 2021 at 07:39, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jun 27, 2021 at 01:06:12PM -0600, Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Fri, 25 Jun 2021 at 10:58, Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Friday 25 June 2021 10:43:11 Simon Glass wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Fri, 25 Jun 2021 at 10:16, Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > On Friday 25 June 2021 10:04:14 Simon Glass wrote:
> > > > > > > But I do wonder about the
> > > > > > > 100KB growth you saw with DT/DM. That seems absolutely enormous to me!
> > > > > > > Can you please point me to the git tree for this? I'd like to
> > > > > > > investigate.
> > > > > >
> > > > > > Patches in this series were written by Ivo. I do not know exact details
> > > > > > and numbers. But the fact is that it was required to enable thumb-2 mode
> > > > > > (which has hw bugs on this cpu, see earlier emails; reason why it was
> > > > > > disabled). If you want to investigate it, you can try compare u-boot
> > > > > > from master/next and u-boot with applying these patches + disable
> > > > > > thumb-2 mode. Note that we have already enabled LTO.
> > > > > >
> > > > >
> > > > > That's probably a little beyond my level of enthusiasm. But if you are
> > > > > able to push a tree with before/after commits, I will take a look.
> > > >
> > > > Hello Simon! I have already pushed these patches to github due to CI
> > > > testing. So you can easily access them via git fetch/checkout.
> > > >
> > > > Before (this is already in u-boot git):
> > > > $ git checkout a298d4fbcdba1b38e48ea2af0fc5386cab2070da
> > > >
> > > > After1:
> > > > $ git fetch https://github.com/u-boot/u-boot.git refs/pull/83/head
> > > > $ git checkout 1f038c8b45ef0018e52a2a4587eb73170769ac2f
> > > >
> > > > After2:
> > > > = use After1 with:
> > > >   + disable CONFIG_SYS_THUMB_BUILD
> > > >   + enable CONFIG_OF_LIBFDT_OVERLAY
> > > >   + enable CONFIG_CMD_FDT
> > > >
> > > > defconfig file is nokia_rx51_defconfig
> > >
> > > OK thanks, I see it. I pushed a tree to u-boot-dm/nokia_rx51 with a
> > > few changes. The growth is about 19KB (without enabling Thumb). Some
> > > more fine-grained control of what get enabled with LIBFDT could be
> > > added to reduce that, perhaps by 5KB.
> >
> > So, was the entirety of the reduction you saw from dropping out
> > EFI_LOADER?  Just most of it?  Disabling that came up in another part of
> > this thread.  And if we just need to disable EFI_LOADER,
> > OF_LIBFDT_OVERLAY and CMD_FDT (and maybe tweak the mask value) in order
> > to not need to do any other changes, yes, that's the right approach.  It
> 
> For me, it dropped the size by about 90KB, although I'm including
> text, rodata and data in that number:
> 
> default
>         arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0
> rodata +10989.0 text +109846.0
> 
> without ebbr
>        arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0
> rodata +5333.0 text +29712.0

OK, so does this mean that with the right options disabled, and without
thumb for now, rx51 can just use a DT?  Pali? Ivaylo?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-26 14:58                                       ` Tom Rini
@ 2021-06-30  7:12                                         ` Ivaylo Dimitrov
  2021-06-30  7:30                                         ` Ivaylo Dimitrov
  1 sibling, 0 replies; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-30  7:12 UTC (permalink / raw)
  To: Tom Rini, Marek Vasut
  Cc: Merlijn Wajer, Pali Rohár, Simon Glass, Lokesh Vutla,
	U-Boot Mailing List, Pavel Machek



On 26.06.21 г. 17:58 ч., Tom Rini wrote:
> On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
>> Hi Tom, Marek,
>>
>> On 25/06/2021 23:59, Tom Rini wrote:
>>> On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
>>>> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
>>>>> One thing I want to say here as I think it maybe wasn't clear in Marek's
>>>>> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
>>>>> on the eMMC?
>>>>
>>>> Hello Tom! I have already answered this in my previous email.
>>>
>>> I just re-read things and I don't see it.  But perhaps I'm not being
>>> clear enough.  Why can't you just have NOLO start SPL, not re-initialize
>>> things (which is a really common case now thanks to aarch64) and just
>>> use that to load full U-Boot from a not size restricted place?
>>>
>>
>> I think there are a few problems.
>>
>> 1. One is a practical one, from Pali's email:
>>
>>> There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
>>
>> Not being able to access the eMMC to write u-boot until u-boot is
>> started does sound like it would make things a bit more tricky.
> 
> I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
> 
>> 2. According to Pali, adding SPL support would not be a trivial task,
>> and might end up with a lot more "#ifdef"s in SPL than the one in
>> Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
>> not do any hardware initialisation on the N900, so that might be where
>> instead hacks would need to be added to SPL.
>>
>> Pali also wrote:
>>
>>> U-Boot for N900 does not use SPL. There is no SPL code implemented.
>>> Nobody ever tried to implement it and neither tested. As you have
>>> correctly pointed instead of SPL is used vendor X-Loader binary, which
>>> is signed by RSA key.
>> And when I asked him today:
>>
>>> 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
>>> 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
>>> 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
>> So perhaps it would make sense to get more clarity on that, since that
>> seems to be where the argument gets stuck.
> 
> This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
> let you skip whatever initialization doesn't need to be done.  If
> there's some init that needs to be skipped but isn't, that's a bug.
> 
>> Also, I'd like to point what Ivaylo wrote earlier:
>>
>>>> This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
>>>
>>> Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
>>>
>>> Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
>>
>> If the other drivers have the same logic, it seems a bit weird to me
>> that the change made in Ivaylo's patch would be rejected because of a
>> preference to port the board to DT. Unless maybe this was the first
>> driver to be migrated to support only DT and the patch is in effect a
>> reversal of some prior work?
> 
> Yes, part of the problem here is that DM_USB is the first case that N900
> has hit as part of DM conversion that written with using OF_CONTROL in
> mind, only.  And he's not interested in taking workarounds to provide
> the required information via another mechanism (while i2c for example,
> is).
> 

It could be that I don't read drivers/usb/host/Makefile right, however, 
what I see there is:

ifdef CONFIG_$(SPL_)DM_USB
obj-y += usb-uclass.o
obj-$(CONFIG_SANDBOX) += usb-sandbox.o
endif

to my understanding one can enable CONFIG_SPL_DM_USB and expect it to 
build. On the other hand it was stated that OF_CONTROL/DT is not 
mandatory for SPL, however, I don't see how is that going to work given 
that drivers/usb/host/usb-uclass.c fails to link without OF_CONTROL (and 
without $subject patch).

So, either DM_USB cannot be enabled for SPL without OF_CONTROL or I am 
in error parsing that Makefile. If the former, then this is a bug the 
$subject patch is fixing as a side effect and yet another reason to 
merge it.

> But another one of the problems here is that N900 doesn't need USB host,
> only USB gadget, and you were disabling some of the host stuff that's
> being built but not used.  A change to not include unused host mode code
> entirely would be another path, and you can address moving to

As I said over the irc, we would really appreciate some hints/help from 
the maintainer(s) on doing that, "please see what can be done" and then 
silence is not really helpful. Not to say shaving the dead weight (in a 
shape of unused hostmode code) does not contradict to the $subject patch.

> DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
> and see if you have to re-visit the OF_CONTROL problem or not.
> >> Of course, in the long run all boards should follow u-boot technological
>> preferences, but it feels a bit off that this patch would be treated
>> differently if the existing drivers already use the same logic, and as
>> far as I can see there is no deadline currently to convert boards to DT,
>> just for converting them to DM.
> 
> The deadline in question here is USB.  It's going on 2 years past due
> and 3 years since the warning was added.  So that we're talking just now
> about the problem, since I started off by just removing the platform,
> isn't great.  And it's not being treated differently, there's no
> U_BOOT_DRVINFOS option for USB, which is where those other #ifdef's are
> related to, I believe.
> 

But, how is DM_USB going to work for SPL? So, either USB should be 
disabled for SPL or DM_USB code must support U_BOOT_DRVINFOS, no?

Ivo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-26 14:58                                       ` Tom Rini
  2021-06-30  7:12                                         ` Ivaylo Dimitrov
@ 2021-06-30  7:30                                         ` Ivaylo Dimitrov
  2021-06-30 13:33                                           ` Tom Rini
  1 sibling, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-30  7:30 UTC (permalink / raw)
  To: Tom Rini, Pali Rohár, Marek Vasut
  Cc: Merlijn Wajer, Simon Glass, Lokesh Vutla, U-Boot Mailing List,
	Pavel Machek

Hi,

On 26.06.21 г. 17:58 ч., Tom Rini wrote:
> On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
>> Hi Tom, Marek,
>>
>> On 25/06/2021 23:59, Tom Rini wrote:
>>> On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
>>>> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
>>>>> One thing I want to say here as I think it maybe wasn't clear in Marek's
>>>>> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
>>>>> on the eMMC?
>>>>
>>>> Hello Tom! I have already answered this in my previous email.
>>>
>>> I just re-read things and I don't see it.  But perhaps I'm not being
>>> clear enough.  Why can't you just have NOLO start SPL, not re-initialize
>>> things (which is a really common case now thanks to aarch64) and just
>>> use that to load full U-Boot from a not size restricted place?
>>>
>>
>> I think there are a few problems.
>>
>> 1. One is a practical one, from Pali's email:
>>
>>> There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
>>
>> Not being able to access the eMMC to write u-boot until u-boot is
>> started does sound like it would make things a bit more tricky.
> 
> I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
> 
>> 2. According to Pali, adding SPL support would not be a trivial task,
>> and might end up with a lot more "#ifdef"s in SPL than the one in
>> Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
>> not do any hardware initialisation on the N900, so that might be where
>> instead hacks would need to be added to SPL.
>>
>> Pali also wrote:
>>
>>> U-Boot for N900 does not use SPL. There is no SPL code implemented.
>>> Nobody ever tried to implement it and neither tested. As you have
>>> correctly pointed instead of SPL is used vendor X-Loader binary, which
>>> is signed by RSA key.
>> And when I asked him today:
>>
>>> 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
>>> 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
>>> 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
>> So perhaps it would make sense to get more clarity on that, since that
>> seems to be where the argument gets stuck.
> 
> This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
> let you skip whatever initialization doesn't need to be done.  If
> there's some init that needs to be skipped but isn't, that's a bug.
> 
>> Also, I'd like to point what Ivaylo wrote earlier:
>>
>>>> This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
>>>
>>> Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
>>>
>>> Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
>>
>> If the other drivers have the same logic, it seems a bit weird to me
>> that the change made in Ivaylo's patch would be rejected because of a
>> preference to port the board to DT. Unless maybe this was the first
>> driver to be migrated to support only DT and the patch is in effect a
>> reversal of some prior work?
> 
> Yes, part of the problem here is that DM_USB is the first case that N900
> has hit as part of DM conversion that written with using OF_CONTROL in
> mind, only.  And he's not interested in taking workarounds to provide
> the required information via another mechanism (while i2c for example,
> is).
> 
> But another one of the problems here is that N900 doesn't need USB host,
> only USB gadget, and you were disabling some of the host stuff that's
> being built but not used.  A change to not include unused host mode code
> entirely would be another path, and you can address moving to
> DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
> and see if you have to re-visit the OF_CONTROL problem or not.
> 

Removing usb-uclass.c and usb_hub.c from the build allows me to enable 
DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without 
-mthumb and runs just fine on a real HW. So I guess this is what we were 
aiming for. Please advice how to proceed - shall I introduce 
CONFIG_USB_HOST Kconfig option that is enabled by default and ifdef 
those files based on it?

Regards,
Ivo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-30  7:30                                         ` Ivaylo Dimitrov
@ 2021-06-30 13:33                                           ` Tom Rini
  2021-06-30 14:31                                             ` Ivaylo Dimitrov
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-30 13:33 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Pali Rohár, Marek Vasut, Merlijn Wajer, Simon Glass,
	Lokesh Vutla, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 6709 bytes --]

On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 26.06.21 г. 17:58 ч., Tom Rini wrote:
> > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
> > > Hi Tom, Marek,
> > > 
> > > On 25/06/2021 23:59, Tom Rini wrote:
> > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
> > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> > > > > > One thing I want to say here as I think it maybe wasn't clear in Marek's
> > > > > > suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> > > > > > on the eMMC?
> > > > > 
> > > > > Hello Tom! I have already answered this in my previous email.
> > > > 
> > > > I just re-read things and I don't see it.  But perhaps I'm not being
> > > > clear enough.  Why can't you just have NOLO start SPL, not re-initialize
> > > > things (which is a really common case now thanks to aarch64) and just
> > > > use that to load full U-Boot from a not size restricted place?
> > > > 
> > > 
> > > I think there are a few problems.
> > > 
> > > 1. One is a practical one, from Pali's email:
> > > 
> > > > There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
> > > 
> > > Not being able to access the eMMC to write u-boot until u-boot is
> > > started does sound like it would make things a bit more tricky.
> > 
> > I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
> > 
> > > 2. According to Pali, adding SPL support would not be a trivial task,
> > > and might end up with a lot more "#ifdef"s in SPL than the one in
> > > Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
> > > not do any hardware initialisation on the N900, so that might be where
> > > instead hacks would need to be added to SPL.
> > > 
> > > Pali also wrote:
> > > 
> > > > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > > > Nobody ever tried to implement it and neither tested. As you have
> > > > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > > > is signed by RSA key.
> > > And when I asked him today:
> > > 
> > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
> > > > 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
> > > > 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
> > > So perhaps it would make sense to get more clarity on that, since that
> > > seems to be where the argument gets stuck.
> > 
> > This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
> > let you skip whatever initialization doesn't need to be done.  If
> > there's some init that needs to be skipped but isn't, that's a bug.
> > 
> > > Also, I'd like to point what Ivaylo wrote earlier:
> > > 
> > > > > This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
> > > > 
> > > > Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
> > > > 
> > > > Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
> > > 
> > > If the other drivers have the same logic, it seems a bit weird to me
> > > that the change made in Ivaylo's patch would be rejected because of a
> > > preference to port the board to DT. Unless maybe this was the first
> > > driver to be migrated to support only DT and the patch is in effect a
> > > reversal of some prior work?
> > 
> > Yes, part of the problem here is that DM_USB is the first case that N900
> > has hit as part of DM conversion that written with using OF_CONTROL in
> > mind, only.  And he's not interested in taking workarounds to provide
> > the required information via another mechanism (while i2c for example,
> > is).
> > 
> > But another one of the problems here is that N900 doesn't need USB host,
> > only USB gadget, and you were disabling some of the host stuff that's
> > being built but not used.  A change to not include unused host mode code
> > entirely would be another path, and you can address moving to
> > DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
> > and see if you have to re-visit the OF_CONTROL problem or not.
> 
> Removing usb-uclass.c and usb_hub.c from the build allows me to enable
> DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without
> -mthumb and runs just fine on a real HW. So I guess this is what we were
> aiming for. Please advice how to proceed - shall I introduce CONFIG_USB_HOST
> Kconfig option that is enabled by default and ifdef those files based on it?

Dropping OF_CONTROL is not a solution.  You're just delaying the problem
until you go to enable DM_USB_GADGET and then once again hitthe case of
needing OF_CONTROL.

I think part of the problem here is that while no, OF_CONTROL is not a
hard requirement, it means that you instead need to implement an
alternative to provide the same information, in a way that keeps you
within the size constraints.  As you've seen with USB, no one has yet
come up with the case of both "we need USB in a very size constrained
area" and "we cannot use OF_CONTROL".

So can we please confirm at run time on the real hardware that there are
thumb problems, and some clever solution will need to be created here
(which will probably be introducing CONFIG_USB_HOST and migrating
CONFIG_USB_DEVICE to Kconfig and then someone from the N900 community
implementing DM_USB_GADGET without OF_CONTROL), or that no, thumb is OK
at runtime after all and the Kconfig cleanup isn't as urgent but still
would be good.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-30 13:33                                           ` Tom Rini
@ 2021-06-30 14:31                                             ` Ivaylo Dimitrov
  2021-06-30 15:48                                               ` Tom Rini
  0 siblings, 1 reply; 36+ messages in thread
From: Ivaylo Dimitrov @ 2021-06-30 14:31 UTC (permalink / raw)
  To: Tom Rini
  Cc: Pali Rohár, Marek Vasut, Merlijn Wajer, Simon Glass,
	Lokesh Vutla, U-Boot Mailing List, Pavel Machek

Hi,

On 30.06.21 г. 16:33 ч., Tom Rini wrote:
> On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 26.06.21 г. 17:58 ч., Tom Rini wrote:
>>> On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
>>>> Hi Tom, Marek,
>>>>
>>>> On 25/06/2021 23:59, Tom Rini wrote:
>>>>> On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
>>>>>> On Friday 25 June 2021 17:37:44 Tom Rini wrote:
>>>>>>> One thing I want to say here as I think it maybe wasn't clear in Marek's
>>>>>>> suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
>>>>>>> on the eMMC?
>>>>>>
>>>>>> Hello Tom! I have already answered this in my previous email.
>>>>>
>>>>> I just re-read things and I don't see it.  But perhaps I'm not being
>>>>> clear enough.  Why can't you just have NOLO start SPL, not re-initialize
>>>>> things (which is a really common case now thanks to aarch64) and just
>>>>> use that to load full U-Boot from a not size restricted place?
>>>>>
>>>>
>>>> I think there are a few problems.
>>>>
>>>> 1. One is a practical one, from Pali's email:
>>>>
>>>>> There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
>>>>
>>>> Not being able to access the eMMC to write u-boot until u-boot is
>>>> started does sound like it would make things a bit more tricky.
>>>
>>> I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
>>>
>>>> 2. According to Pali, adding SPL support would not be a trivial task,
>>>> and might end up with a lot more "#ifdef"s in SPL than the one in
>>>> Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
>>>> not do any hardware initialisation on the N900, so that might be where
>>>> instead hacks would need to be added to SPL.
>>>>
>>>> Pali also wrote:
>>>>
>>>>> U-Boot for N900 does not use SPL. There is no SPL code implemented.
>>>>> Nobody ever tried to implement it and neither tested. As you have
>>>>> correctly pointed instead of SPL is used vendor X-Loader binary, which
>>>>> is signed by RSA key.
>>>> And when I asked him today:
>>>>
>>>>> 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
>>>>> 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
>>>>> 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
>>>> So perhaps it would make sense to get more clarity on that, since that
>>>> seems to be where the argument gets stuck.
>>>
>>> This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
>>> let you skip whatever initialization doesn't need to be done.  If
>>> there's some init that needs to be skipped but isn't, that's a bug.
>>>
>>>> Also, I'd like to point what Ivaylo wrote earlier:
>>>>
>>>>>> This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
>>>>>
>>>>> Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
>>>>>
>>>>> Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
>>>>
>>>> If the other drivers have the same logic, it seems a bit weird to me
>>>> that the change made in Ivaylo's patch would be rejected because of a
>>>> preference to port the board to DT. Unless maybe this was the first
>>>> driver to be migrated to support only DT and the patch is in effect a
>>>> reversal of some prior work?
>>>
>>> Yes, part of the problem here is that DM_USB is the first case that N900
>>> has hit as part of DM conversion that written with using OF_CONTROL in
>>> mind, only.  And he's not interested in taking workarounds to provide
>>> the required information via another mechanism (while i2c for example,
>>> is).
>>>
>>> But another one of the problems here is that N900 doesn't need USB host,
>>> only USB gadget, and you were disabling some of the host stuff that's
>>> being built but not used.  A change to not include unused host mode code
>>> entirely would be another path, and you can address moving to
>>> DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
>>> and see if you have to re-visit the OF_CONTROL problem or not.
>>
>> Removing usb-uclass.c and usb_hub.c from the build allows me to enable
>> DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without
>> -mthumb and runs just fine on a real HW. So I guess this is what we were
>> aiming for. Please advice how to proceed - shall I introduce CONFIG_USB_HOST
>> Kconfig option that is enabled by default and ifdef those files based on it?
> 
> Dropping OF_CONTROL is not a solution.  You're just delaying the problem
> until you go to enable DM_USB_GADGET and then once again hitthe case of
> needing OF_CONTROL.
> 

Let worry about it when we have to. If we delay it for long enough, the 
problem will resolve by itself, as there will be no more HW to support 
:). So, we have another issue here, IIUC.

> I think part of the problem here is that while no, OF_CONTROL is not a
> hard requirement, it means that you instead need to implement an
> alternative to provide the same information, in a way that keeps you
> within the size constraints.  As you've seen with USB, no one has yet
> come up with the case of both "we need USB in a very size constrained
> area" and "we cannot use OF_CONTROL".
> 

It is not about OF_CONTROL (only), it is about including code which is 
never used (hostmode stuff). Even if we do DT migration and whatnot, the 
code in usb-uclass.c and usb_hub.c will still be not used on N900, so I 
don't really understand why you insist on having it included on a 
gadget-only device. Or, you say that if we move to DM_USB_GADGET, 
hostmode code is not going to be included? Please elaborate.

In case of N900, no DT information is needed to be provided for USB 
gadget mode to work and hostmode code (that seems to require DT and 
stuff) is simply not needed.

Also, could you comment on SPL and DM_USB, please see my other email.

> So can we please confirm at run time on the real hardware that there are
> thumb problems, and some clever solution will need to be created here
> (which will probably be introducing CONFIG_USB_HOST and migrating
> CONFIG_USB_DEVICE to Kconfig and then someone from the N900 community
> implementing DM_USB_GADGET without OF_CONTROL), or that no, thumb is OK
> at runtime after all and the Kconfig cleanup isn't as urgent but still
> would be good.
> 

And how exactly we are supposed to confirm if thumb2 is ok or not? Do 
you have a good test-case? My gut feeling tells me thumb2 is fine, but I 
can neither prove nor disprove it. NOLO itself uses thumb2 code, so I 
guess we can assume it to be safe to use it for u-boot.

But still, the code size is not the main issue to me, it is that you 
seem to implicitly mandate something that is still not mandatory to my 
knowledge - migration to DT. Could you please at least define what is 
the deadline for us to finish with it?

Regards,
Ivo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-30 14:31                                             ` Ivaylo Dimitrov
@ 2021-06-30 15:48                                               ` Tom Rini
  2021-06-30 16:02                                                 ` Simon Glass
  0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2021-06-30 15:48 UTC (permalink / raw)
  To: Ivaylo Dimitrov
  Cc: Pali Rohár, Marek Vasut, Merlijn Wajer, Simon Glass,
	Lokesh Vutla, U-Boot Mailing List, Pavel Machek

[-- Attachment #1: Type: text/plain, Size: 12285 bytes --]

On Wed, Jun 30, 2021 at 05:31:44PM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 30.06.21 г. 16:33 ч., Tom Rini wrote:
> > On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote:
> > > Hi,
> > > 
> > > On 26.06.21 г. 17:58 ч., Tom Rini wrote:
> > > > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
> > > > > Hi Tom, Marek,
> > > > > 
> > > > > On 25/06/2021 23:59, Tom Rini wrote:
> > > > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
> > > > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> > > > > > > > One thing I want to say here as I think it maybe wasn't clear in Marek's
> > > > > > > > suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> > > > > > > > on the eMMC?
> > > > > > > 
> > > > > > > Hello Tom! I have already answered this in my previous email.
> > > > > > 
> > > > > > I just re-read things and I don't see it.  But perhaps I'm not being
> > > > > > clear enough.  Why can't you just have NOLO start SPL, not re-initialize
> > > > > > things (which is a really common case now thanks to aarch64) and just
> > > > > > use that to load full U-Boot from a not size restricted place?
> > > > > > 
> > > > > 
> > > > > I think there are a few problems.
> > > > > 
> > > > > 1. One is a practical one, from Pali's email:
> > > > > 
> > > > > > There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
> > > > > 
> > > > > Not being able to access the eMMC to write u-boot until u-boot is
> > > > > started does sound like it would make things a bit more tricky.
> > > > 
> > > > I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
> > > > 
> > > > > 2. According to Pali, adding SPL support would not be a trivial task,
> > > > > and might end up with a lot more "#ifdef"s in SPL than the one in
> > > > > Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
> > > > > not do any hardware initialisation on the N900, so that might be where
> > > > > instead hacks would need to be added to SPL.
> > > > > 
> > > > > Pali also wrote:
> > > > > 
> > > > > > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > > > > > Nobody ever tried to implement it and neither tested. As you have
> > > > > > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > > > > > is signed by RSA key.
> > > > > And when I asked him today:
> > > > > 
> > > > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
> > > > > > 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
> > > > > > 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
> > > > > So perhaps it would make sense to get more clarity on that, since that
> > > > > seems to be where the argument gets stuck.
> > > > 
> > > > This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
> > > > let you skip whatever initialization doesn't need to be done.  If
> > > > there's some init that needs to be skipped but isn't, that's a bug.
> > > > 
> > > > > Also, I'd like to point what Ivaylo wrote earlier:
> > > > > 
> > > > > > > This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
> > > > > > 
> > > > > > Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
> > > > > > 
> > > > > > Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
> > > > > 
> > > > > If the other drivers have the same logic, it seems a bit weird to me
> > > > > that the change made in Ivaylo's patch would be rejected because of a
> > > > > preference to port the board to DT. Unless maybe this was the first
> > > > > driver to be migrated to support only DT and the patch is in effect a
> > > > > reversal of some prior work?
> > > > 
> > > > Yes, part of the problem here is that DM_USB is the first case that N900
> > > > has hit as part of DM conversion that written with using OF_CONTROL in
> > > > mind, only.  And he's not interested in taking workarounds to provide
> > > > the required information via another mechanism (while i2c for example,
> > > > is).
> > > > 
> > > > But another one of the problems here is that N900 doesn't need USB host,
> > > > only USB gadget, and you were disabling some of the host stuff that's
> > > > being built but not used.  A change to not include unused host mode code
> > > > entirely would be another path, and you can address moving to
> > > > DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
> > > > and see if you have to re-visit the OF_CONTROL problem or not.
> > > 
> > > Removing usb-uclass.c and usb_hub.c from the build allows me to enable
> > > DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without
> > > -mthumb and runs just fine on a real HW. So I guess this is what we were
> > > aiming for. Please advice how to proceed - shall I introduce CONFIG_USB_HOST
> > > Kconfig option that is enabled by default and ifdef those files based on it?
> > 
> > Dropping OF_CONTROL is not a solution.  You're just delaying the problem
> > until you go to enable DM_USB_GADGET and then once again hitthe case of
> > needing OF_CONTROL.
> 
> Let worry about it when we have to. If we delay it for long enough, the
> problem will resolve by itself, as there will be no more HW to support :).
> So, we have another issue here, IIUC.

I know you're joking here, but I don't think that helps.  Looking over
all of the N900 related USB code has left me a bit depressed.  It's not
a trivial DM_USB_GADGET conversion because the platform hasn't been
converted to our nearly 10 year old "new" USB_GADGET framework and
almost 9 year old "new" MUSB driver port.  And in the end, it's both
doable (there's other omap3 platforms, with and without DM_USB_GADGET
and in turn OF_CONTROL) but a challenge as usbtty is the main (only?)
gadget N900 cares about, and that's not converted to anything modern
either.

> > I think part of the problem here is that while no, OF_CONTROL is not a
> > hard requirement, it means that you instead need to implement an
> > alternative to provide the same information, in a way that keeps you
> > within the size constraints.  As you've seen with USB, no one has yet
> > come up with the case of both "we need USB in a very size constrained
> > area" and "we cannot use OF_CONTROL".
> 
> It is not about OF_CONTROL (only), it is about including code which is never
> used (hostmode stuff). Even if we do DT migration and whatnot, the code in
> usb-uclass.c and usb_hub.c will still be not used on N900, so I don't really
> understand why you insist on having it included on a gadget-only device. Or,
> you say that if we move to DM_USB_GADGET, hostmode code is not going to be
> included? Please elaborate.

The good thing is this has shown that indeed, we build some host stuff
when not needed, and should stop doing that.  The bad thing is it's
shown piles of other technical debt.

To put this another way, I can silence the warning with:
diff --git a/Makefile b/Makefile
index 027e31e09e4c..96d3eaa18add 100644
--- a/Makefile
+++ b/Makefile
@@ -824,7 +824,7 @@ libs-y += drivers/usb/eth/
 libs-$(CONFIG_USB_DEVICE) += drivers/usb/gadget/
 libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/
 libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/udc/
-libs-y += drivers/usb/host/
+libs-$(CONFIG_USB_HOST) += drivers/usb/host/
 libs-y += drivers/usb/mtu3/
 libs-y += drivers/usb/musb/
 libs-y += drivers/usb/musb-new/
@@ -1115,7 +1115,7 @@ ifneq ($(CONFIG_DM),y)
 	@echo >&2 "===================================================="
 endif
 	$(call deprecated,CONFIG_DM_USB CONFIG_OF_CONTROL CONFIG_BLK,\
-		USB,v2019.07,$(CONFIG_USB))
+		USB_HOST,v2019.07,$(CONFIG_USB_HOST))
 	$(call deprecated,CONFIG_DM_PCI,PCI,v2019.07,$(CONFIG_PCI))
 	$(call deprecated,CONFIG_DM_VIDEO,video,v2019.07,\
 		$(CONFIG_LCD)$(CONFIG_VIDEO))
diff --git a/cmd/Kconfig b/cmd/Kconfig
index a9fb4eead29b..a13a68f8f333 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1322,7 +1322,7 @@ config CMD_UNIVERSE
 
 config CMD_USB
 	bool "usb"
-	depends on USB
+	depends on USB_HOST
 	select HAVE_BLOCK_DEVICE
 	help
 	  USB support.

and this is mostly right, but there's a few host drivers that don't
depends on USB_HOST like they should.  But it still leaves nokia_rx51
with piles of technical debt.  There's just no screaming warnings.

What's the best way to get attention drawn to all of the bits of
technical debt that are left, and not just on this platform?  I don't
know.  I was hoping the build time warnings we have would have helped,
but as shown by this case here, they have not.  And honestly, this isn't
the first platform to near the deadline come up and ask for some sort of
reprieve.

> In case of N900, no DT information is needed to be provided for USB gadget
> mode to work and hostmode code (that seems to require DT and stuff) is
> simply not needed.

Because of using very old code, yes.

> Also, could you comment on SPL and DM_USB, please see my other email.

I did in this email.  No one requires SPL_DM_USB && !SPL_OF_CONTROL
today, so no one has made it work.

> > So can we please confirm at run time on the real hardware that there are
> > thumb problems, and some clever solution will need to be created here
> > (which will probably be introducing CONFIG_USB_HOST and migrating
> > CONFIG_USB_DEVICE to Kconfig and then someone from the N900 community
> > implementing DM_USB_GADGET without OF_CONTROL), or that no, thumb is OK
> > at runtime after all and the Kconfig cleanup isn't as urgent but still
> > would be good.
> 
> And how exactly we are supposed to confirm if thumb2 is ok or not? Do you
> have a good test-case? My gut feeling tells me thumb2 is fine, but I can
> neither prove nor disprove it. NOLO itself uses thumb2 code, so I guess we
> can assume it to be safe to use it for u-boot.

Does it boot to Linux?  That's really all we check for with
test/nokia_rx51_test.sh but I wish it would get hooked up to also run
our pytest framework.  That framework can also be used on real hardware,
and running those tests would be real nice to see too.  But that's all
an aside, at this point.

> But still, the code size is not the main issue to me, it is that you seem to
> implicitly mandate something that is still not mandatory to my knowledge -
> migration to DT. Could you please at least define what is the deadline for
> us to finish with it?

Well, DT migration isn't required if you update a given subsystem to be
able to be given the required platform information via another mechanism
such as how you're using U_BOOT_DRVINFOS today with i2c.  But the
flipside is that subsystems do not have to support a non-DT way, and USB
does not currently have a non-DT way.  Using U_BOOT_DRVINFOS is
discouraged when OF_CONTROL is possible instead.

And I want to say finally, I've redrafted this email a few times now,
and I want to apologize now if this comes out cranky or mean, it's not
my intention.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
  2021-06-30 15:48                                               ` Tom Rini
@ 2021-06-30 16:02                                                 ` Simon Glass
  0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2021-06-30 16:02 UTC (permalink / raw)
  To: Tom Rini
  Cc: Ivaylo Dimitrov, Pali Rohár, Marek Vasut, Merlijn Wajer,
	Lokesh Vutla, U-Boot Mailing List, Pavel Machek

Hi Tom,

On Wed, 30 Jun 2021 at 09:49, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jun 30, 2021 at 05:31:44PM +0300, Ivaylo Dimitrov wrote:
> > Hi,
> >
> > On 30.06.21 г. 16:33 ч., Tom Rini wrote:
> > > On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote:
> > > > Hi,
> > > >
> > > > On 26.06.21 г. 17:58 ч., Tom Rini wrote:
> > > > > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
> > > > > > Hi Tom, Marek,
> > > > > >
> > > > > > On 25/06/2021 23:59, Tom Rini wrote:
> > > > > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
> > > > > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote:
> > > > > > > > > One thing I want to say here as I think it maybe wasn't clear in Marek's
> > > > > > > > > suggestion.  Why not have X-Loader boot SPL which loads U-Boot from extN
> > > > > > > > > on the eMMC?
> > > > > > > >
> > > > > > > > Hello Tom! I have already answered this in my previous email.
> > > > > > >
> > > > > > > I just re-read things and I don't see it.  But perhaps I'm not being
> > > > > > > clear enough.  Why can't you just have NOLO start SPL, not re-initialize
> > > > > > > things (which is a really common case now thanks to aarch64) and just
> > > > > > > use that to load full U-Boot from a not size restricted place?
> > > > > > >
> > > > > >
> > > > > > I think there are a few problems.
> > > > > >
> > > > > > 1. One is a practical one, from Pali's email:
> > > > > >
> > > > > > > There is no easy access to eMMC until you start full U-Boot. So even if  all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop.
> > > > > >
> > > > > > Not being able to access the eMMC to write u-boot until u-boot is
> > > > > > started does sound like it would make things a bit more tricky.
> > > > >
> > > > > I don't understand this.  Either way it's drivers/mmc/omap_hsmmc.c.
> > > > >
> > > > > > 2. According to Pali, adding SPL support would not be a trivial task,
> > > > > > and might end up with a lot more "#ifdef"s in SPL than the one in
> > > > > > Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
> > > > > > not do any hardware initialisation on the N900, so that might be where
> > > > > > instead hacks would need to be added to SPL.
> > > > > >
> > > > > > Pali also wrote:
> > > > > >
> > > > > > > U-Boot for N900 does not use SPL. There is no SPL code implemented.
> > > > > > > Nobody ever tried to implement it and neither tested. As you have
> > > > > > > correctly pointed instead of SPL is used vendor X-Loader binary, which
> > > > > > > is signed by RSA key.
> > > > > > And when I asked him today:
> > > > > >
> > > > > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
> > > > > > > 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
> > > > > > > 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
> > > > > > So perhaps it would make sense to get more clarity on that, since that
> > > > > > seems to be where the argument gets stuck.
> > > > >
> > > > > This also doesn't make sense to me.  CONFIG_SKIP_LOWLEVEL_INIT should
> > > > > let you skip whatever initialization doesn't need to be done.  If
> > > > > there's some init that needs to be skipped but isn't, that's a bug.
> > > > >
> > > > > > Also, I'd like to point what Ivaylo wrote earlier:
> > > > > >
> > > > > > > > This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it.
> > > > > > >
> > > > > > > Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only.
> > > > > > >
> > > > > > > Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing.
> > > > > >
> > > > > > If the other drivers have the same logic, it seems a bit weird to me
> > > > > > that the change made in Ivaylo's patch would be rejected because of a
> > > > > > preference to port the board to DT. Unless maybe this was the first
> > > > > > driver to be migrated to support only DT and the patch is in effect a
> > > > > > reversal of some prior work?
> > > > >
> > > > > Yes, part of the problem here is that DM_USB is the first case that N900
> > > > > has hit as part of DM conversion that written with using OF_CONTROL in
> > > > > mind, only.  And he's not interested in taking workarounds to provide
> > > > > the required information via another mechanism (while i2c for example,
> > > > > is).
> > > > >
> > > > > But another one of the problems here is that N900 doesn't need USB host,
> > > > > only USB gadget, and you were disabling some of the host stuff that's
> > > > > being built but not used.  A change to not include unused host mode code
> > > > > entirely would be another path, and you can address moving to
> > > > > DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
> > > > > and see if you have to re-visit the OF_CONTROL problem or not.
> > > >
> > > > Removing usb-uclass.c and usb_hub.c from the build allows me to enable
> > > > DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without
> > > > -mthumb and runs just fine on a real HW. So I guess this is what we were
> > > > aiming for. Please advice how to proceed - shall I introduce CONFIG_USB_HOST
> > > > Kconfig option that is enabled by default and ifdef those files based on it?
> > >
> > > Dropping OF_CONTROL is not a solution.  You're just delaying the problem
> > > until you go to enable DM_USB_GADGET and then once again hitthe case of
> > > needing OF_CONTROL.
> >
> > Let worry about it when we have to. If we delay it for long enough, the
> > problem will resolve by itself, as there will be no more HW to support :).
> > So, we have another issue here, IIUC.
>
> I know you're joking here, but I don't think that helps.  Looking over
> all of the N900 related USB code has left me a bit depressed.  It's not
> a trivial DM_USB_GADGET conversion because the platform hasn't been
> converted to our nearly 10 year old "new" USB_GADGET framework and
> almost 9 year old "new" MUSB driver port.  And in the end, it's both
> doable (there's other omap3 platforms, with and without DM_USB_GADGET
> and in turn OF_CONTROL) but a challenge as usbtty is the main (only?)
> gadget N900 cares about, and that's not converted to anything modern
> either.
>
> > > I think part of the problem here is that while no, OF_CONTROL is not a
> > > hard requirement, it means that you instead need to implement an
> > > alternative to provide the same information, in a way that keeps you
> > > within the size constraints.  As you've seen with USB, no one has yet
> > > come up with the case of both "we need USB in a very size constrained
> > > area" and "we cannot use OF_CONTROL".
> >
> > It is not about OF_CONTROL (only), it is about including code which is never
> > used (hostmode stuff). Even if we do DT migration and whatnot, the code in
> > usb-uclass.c and usb_hub.c will still be not used on N900, so I don't really
> > understand why you insist on having it included on a gadget-only device. Or,
> > you say that if we move to DM_USB_GADGET, hostmode code is not going to be
> > included? Please elaborate.
>
> The good thing is this has shown that indeed, we build some host stuff
> when not needed, and should stop doing that.  The bad thing is it's
> shown piles of other technical debt.
>
> To put this another way, I can silence the warning with:
> diff --git a/Makefile b/Makefile
> index 027e31e09e4c..96d3eaa18add 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -824,7 +824,7 @@ libs-y += drivers/usb/eth/
>  libs-$(CONFIG_USB_DEVICE) += drivers/usb/gadget/
>  libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/
>  libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/udc/
> -libs-y += drivers/usb/host/
> +libs-$(CONFIG_USB_HOST) += drivers/usb/host/
>  libs-y += drivers/usb/mtu3/
>  libs-y += drivers/usb/musb/
>  libs-y += drivers/usb/musb-new/
> @@ -1115,7 +1115,7 @@ ifneq ($(CONFIG_DM),y)
>         @echo >&2 "===================================================="
>  endif
>         $(call deprecated,CONFIG_DM_USB CONFIG_OF_CONTROL CONFIG_BLK,\
> -               USB,v2019.07,$(CONFIG_USB))
> +               USB_HOST,v2019.07,$(CONFIG_USB_HOST))
>         $(call deprecated,CONFIG_DM_PCI,PCI,v2019.07,$(CONFIG_PCI))
>         $(call deprecated,CONFIG_DM_VIDEO,video,v2019.07,\
>                 $(CONFIG_LCD)$(CONFIG_VIDEO))
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index a9fb4eead29b..a13a68f8f333 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1322,7 +1322,7 @@ config CMD_UNIVERSE
>
>  config CMD_USB
>         bool "usb"
> -       depends on USB
> +       depends on USB_HOST
>         select HAVE_BLOCK_DEVICE
>         help
>           USB support.
>
> and this is mostly right, but there's a few host drivers that don't
> depends on USB_HOST like they should.  But it still leaves nokia_rx51
> with piles of technical debt.  There's just no screaming warnings.
>
> What's the best way to get attention drawn to all of the bits of
> technical debt that are left, and not just on this platform?  I don't
> know.  I was hoping the build time warnings we have would have helped,
> but as shown by this case here, they have not.  And honestly, this isn't
> the first platform to near the deadline come up and ask for some sort of
> reprieve.
>
> > In case of N900, no DT information is needed to be provided for USB gadget
> > mode to work and hostmode code (that seems to require DT and stuff) is
> > simply not needed.
>
> Because of using very old code, yes.
>
> > Also, could you comment on SPL and DM_USB, please see my other email.
>
> I did in this email.  No one requires SPL_DM_USB && !SPL_OF_CONTROL
> today, so no one has made it work.
>
> > > So can we please confirm at run time on the real hardware that there are
> > > thumb problems, and some clever solution will need to be created here
> > > (which will probably be introducing CONFIG_USB_HOST and migrating
> > > CONFIG_USB_DEVICE to Kconfig and then someone from the N900 community
> > > implementing DM_USB_GADGET without OF_CONTROL), or that no, thumb is OK
> > > at runtime after all and the Kconfig cleanup isn't as urgent but still
> > > would be good.
> >
> > And how exactly we are supposed to confirm if thumb2 is ok or not? Do you
> > have a good test-case? My gut feeling tells me thumb2 is fine, but I can
> > neither prove nor disprove it. NOLO itself uses thumb2 code, so I guess we
> > can assume it to be safe to use it for u-boot.
>
> Does it boot to Linux?  That's really all we check for with
> test/nokia_rx51_test.sh but I wish it would get hooked up to also run
> our pytest framework.  That framework can also be used on real hardware,
> and running those tests would be real nice to see too.  But that's all
> an aside, at this point.
>
> > But still, the code size is not the main issue to me, it is that you seem to
> > implicitly mandate something that is still not mandatory to my knowledge -
> > migration to DT. Could you please at least define what is the deadline for
> > us to finish with it?
>
> Well, DT migration isn't required if you update a given subsystem to be
> able to be given the required platform information via another mechanism
> such as how you're using U_BOOT_DRVINFOS today with i2c.  But the
> flipside is that subsystems do not have to support a non-DT way, and USB
> does not currently have a non-DT way.  Using U_BOOT_DRVINFOS is
> discouraged when OF_CONTROL is possible instead.
>
> And I want to say finally, I've redrafted this email a few times now,
> and I want to apologize now if this comes out cranky or mean, it's not
> my intention.

Somewhat more broadly...

IMO there is a lot of energy invested in discussions about migration.
I feel that energy would be better invested in moving things forward.
In other words, why so much discussion about whether to migrate X to
the latest thing?

Being a custodian of a board does have some responsibilities. Perhaps
we need to have a dashboard for each maintainer, showing the things
that need to be addressed? Something seems wrong with the current
process, where every migration generates so much push-back and
discussion.

Regards,
Simon

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2021-06-30 16:02 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-18 14:57 [PATCH 1/2] DM_USB: allow building without OF_CONTROL Pali Rohár
2021-06-18 14:57 ` [PATCH 2/2] Nokia RX-51: Enable CONFIG_DM_USB to remove deprecation warning Pali Rohár
2021-06-26 18:31   ` Simon Glass
2021-06-18 16:38 ` [PATCH 1/2] DM_USB: allow building without OF_CONTROL Tom Rini
2021-06-19  2:23   ` Marek Vasut
2021-06-19  6:14     ` Ivaylo Dimitrov
2021-06-19 18:17       ` Marek Vasut
2021-06-19 19:33         ` Ivaylo Dimitrov
2021-06-19 19:38           ` Marek Vasut
2021-06-19 20:15             ` Ivaylo Dimitrov
2021-06-19 20:51               ` Tom Rini
2021-06-20  3:52                 ` Marek Vasut
2021-06-20 15:54                   ` Tom Rini
2021-06-20 19:43                     ` Marek Vasut
2021-06-25 12:38                       ` Tom Rini
2021-06-25 13:07                         ` Pali Rohár
2021-06-25 16:04                           ` Simon Glass
2021-06-25 16:16                             ` Pali Rohár
2021-06-25 16:43                               ` Simon Glass
2021-06-25 16:58                                 ` Pali Rohár
2021-06-27 19:06                                   ` Simon Glass
2021-06-28 13:39                                     ` Tom Rini
2021-06-28 14:20                                       ` Simon Glass
2021-06-28 14:43                                         ` Tom Rini
2021-06-25 21:31                             ` Ivaylo Dimitrov
2021-06-25 21:37                               ` Tom Rini
2021-06-25 21:51                                 ` Pali Rohár
2021-06-25 21:59                                   ` Tom Rini
2021-06-26 10:59                                     ` Merlijn Wajer
2021-06-26 14:58                                       ` Tom Rini
2021-06-30  7:12                                         ` Ivaylo Dimitrov
2021-06-30  7:30                                         ` Ivaylo Dimitrov
2021-06-30 13:33                                           ` Tom Rini
2021-06-30 14:31                                             ` Ivaylo Dimitrov
2021-06-30 15:48                                               ` Tom Rini
2021-06-30 16:02                                                 ` Simon Glass

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.