[PATCH 1/2] arm: mvebu: clearfog: add SCSI to distro bootcmd

Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
---
include/configs/clearfog.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..a452f4b009 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -110,9 +110,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif
+#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \ + BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)

Enabled distro bootcmd support for additional SATA ports if enabled.
Signed-off-by: Joel Johnson mrjoel@lixil.net
---
This patch builds on and requires the separate patch series adding configurable SATA support ("arm: mvebu: clearfog: Add SATA mode flags").
--- include/configs/clearfog.h | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index a452f4b009..0bf7e9d950 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -111,15 +111,40 @@ #endif
#ifdef CONFIG_SCSI -#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func) func(SCSI, scsi, 0) + +/* + * Either one or both mPCIe slots may be configured as mSATA interfaces. The + * SCSI bus ids are assigned based on sequence of hardware present, not always + * tied to hardware slot ids. As such, use second SCSI bus if either slot is + * set for SATA, and only use third SCSI bus if both slots are SATA enabled. + */ +#if defined (CONFIG_CLEARFOG_CON2_SATA) || defined (CONFIG_CLEARFOG_CON3_SATA) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) func(SCSI, scsi, 1) +#else +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) +#endif + +#if defined (CONFIG_CLEARFOG_CON2_SATA) && defined (CONFIG_CLEARFOG_CON3_SATA) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) func(SCSI, scsi, 2) #else -#define BOOT_TARGET_DEVICES_SCSI(func) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) #endif
+#else +#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func) +#endif /* CONFIG_SCSI */ + +/* + * The SCSI buses are attempted in increasing bus order, there is no current + * mechanism to alter the default bus priority order for booting. + */ #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \ - BOOT_TARGET_DEVICES_SCSI(func) \ + BOOT_TARGET_DEVICES_SCSI_M2SATA(func) \ + BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) \ + BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)

Added Josua to Cc.
On 29.01.20 04:59, Joel Johnson wrote:
Enabled distro bootcmd support for additional SATA ports if enabled.
Signed-off-by: Joel Johnson mrjoel@lixil.net
This patch builds on and requires the separate patch series adding configurable SATA support ("arm: mvebu: clearfog: Add SATA mode flags").
include/configs/clearfog.h | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index a452f4b009..0bf7e9d950 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -111,15 +111,40 @@ #endif
#ifdef CONFIG_SCSI -#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func) func(SCSI, scsi, 0)
+/*
- Either one or both mPCIe slots may be configured as mSATA interfaces. The
- SCSI bus ids are assigned based on sequence of hardware present, not always
- tied to hardware slot ids. As such, use second SCSI bus if either slot is
- set for SATA, and only use third SCSI bus if both slots are SATA enabled.
- */
+#if defined (CONFIG_CLEARFOG_CON2_SATA) || defined (CONFIG_CLEARFOG_CON3_SATA) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) func(SCSI, scsi, 1) +#else +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) +#endif
+#if defined (CONFIG_CLEARFOG_CON2_SATA) && defined (CONFIG_CLEARFOG_CON3_SATA) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) func(SCSI, scsi, 2) #else -#define BOOT_TARGET_DEVICES_SCSI(func) +#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) #endif
+#else +#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func) +#endif /* CONFIG_SCSI */
+/*
- The SCSI buses are attempted in increasing bus order, there is no current
- mechanism to alter the default bus priority order for booting.
- */ #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \
- BOOT_TARGET_DEVICES_SCSI(func) \
- BOOT_TARGET_DEVICES_SCSI_M2SATA(func) \
- BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) \
- BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)
Josua, Baruch, any comments from you on this one?
Thanks, Stefan

As with other related ClearFog patches, I haven't received any review responses on this series (http://patchwork.ozlabs.org/project/uboot/list/?series=155760) and would like to ping out for additional review. I'd especially like feedback on the approach for support of multiple SCSI devices, if there a preferred or standardized mechanism I'd be happy to adjust, but I couldn't find any other examples of including multiple SCSI devices in distro_boot. In reviewing again myself there was an initial mental mismatch between CON2/CON3 usage as connection ports and the naming of SCSI_CLEARFOG2/SCSI_CLEARFOG3 as index counters, but otherwise still seems good.
If it's in an acceptable state for inclusion in the next merge window, that's certainly fine too, I'm just looking for a crosscheck.
Thanks! Joel
On 2020-01-28 20:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
include/configs/clearfog.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..a452f4b009 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -110,9 +110,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif
+#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif
#define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \
- BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)

Hi Joel,
On 22.03.20 19:53, Joel Johnson wrote:
As with other related ClearFog patches, I haven't received any review responses on this series (http://patchwork.ozlabs.org/project/uboot/list/?series=155760) and would like to ping out for additional review. I'd especially like feedback on the approach for support of multiple SCSI devices, if there a preferred or standardized mechanism I'd be happy to adjust, but I couldn't find any other examples of including multiple SCSI devices in distro_boot. In reviewing again myself there was an initial mental mismatch between CON2/CON3 usage as connection ports and the naming of SCSI_CLEARFOG2/SCSI_CLEARFOG3 as index counters, but otherwise still seems good.
If it's in an acceptable state for inclusion in the next merge window, that's certainly fine too, I'm just looking for a crosscheck.
Let's see, if Baruch and/or Josua have some comments here.
Thanks, Stefan
Thanks! Joel
On 2020-01-28 20:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
include/configs/clearfog.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..a452f4b009 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -110,9 +110,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif
+#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif
#define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \ + BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)
Viele Grüße, Stefan

On 2020-03-23 04:27, Stefan Roese wrote:
Hi Joel,
On 22.03.20 19:53, Joel Johnson wrote:
As with other related ClearFog patches, I haven't received any review responses on this series (http://patchwork.ozlabs.org/project/uboot/list/?series=155760) and would like to ping out for additional review. I'd especially like feedback on the approach for support of multiple SCSI devices, if there a preferred or standardized mechanism I'd be happy to adjust, but I couldn't find any other examples of including multiple SCSI devices in distro_boot. In reviewing again myself there was an initial mental mismatch between CON2/CON3 usage as connection ports and the naming of SCSI_CLEARFOG2/SCSI_CLEARFOG3 as index counters, but otherwise still seems good.
If it's in an acceptable state for inclusion in the next merge window, that's certainly fine too, I'm just looking for a crosscheck.
Let's see, if Baruch and/or Josua have some comments here.
Thanks, Stefan
I have an update I'll post shortly which keeps the same logic, but renames the defined macros to be SCSI bus centric (i.e. X_BUS0, X_BUS1, X_BUS2) instead of potential confusion with hardware labelled port locations.
Joel

Added Josua to Cc.
On 29.01.20 04:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
Josua posted a similar patch (different order though):
http://patchwork.ozlabs.org/patch/1239539/
I tend to pull your patch though in the next merge window, if nobody objects. So:
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
include/configs/clearfog.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..a452f4b009 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -110,9 +110,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif
+#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif
- #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \
- BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na)

On 2020-03-23 04:20, Stefan Roese wrote:
Added Josua to Cc.
On 29.01.20 04:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
Josua posted a similar patch (different order though):
http://patchwork.ozlabs.org/patch/1239539/
I tend to pull your patch though in the next merge window, if nobody objects. So:
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
I just wanted to send a bump on this series. With the first pull request of the merge window you merged Josua's patch. I'd still advocate for my original reasoning on the boot order priority, but in either case the second patch in this series is unique and non-conflicting since it adds support for the additional SCSI buses depending on configuration.
Josua - any objection to moving USB boot before SCSI in the priority order?
I'll rebase the series on current master since it will conflict, but wanted to try to get consensus on the approach before doing so.
Thanks!
Joel

On 16.04.20 06:09, Joel Johnson wrote:
On 2020-03-23 04:20, Stefan Roese wrote:
Added Josua to Cc.
On 29.01.20 04:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
Josua posted a similar patch (different order though):
http://patchwork.ozlabs.org/patch/1239539/
I tend to pull your patch though in the next merge window, if nobody objects. So:
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
I just wanted to send a bump on this series. With the first pull request of the merge window you merged Josua's patch. I'd still advocate for my original reasoning on the boot order priority, but in either case the second patch in this series is unique and non-conflicting since it adds support for the additional SCSI buses depending on configuration.
Josua - any objection to moving USB boot before SCSI in the priority order?
I'll rebase the series on current master since it will conflict, but wanted to try to get consensus on the approach before doing so.
Okay from me for this.
Thanks, Stefan

On 2020-04-16 00:13, Stefan Roese wrote:
On 16.04.20 06:09, Joel Johnson wrote:
On 2020-03-23 04:20, Stefan Roese wrote:
Added Josua to Cc.
On 29.01.20 04:59, Joel Johnson wrote:
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson mrjoel@lixil.net
Josua posted a similar patch (different order though):
http://patchwork.ozlabs.org/patch/1239539/
I tend to pull your patch though in the next merge window, if nobody objects. So:
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
I just wanted to send a bump on this series. With the first pull request of the merge window you merged Josua's patch. I'd still advocate for my original reasoning on the boot order priority, but in either case the second patch in this series is unique and non-conflicting since it adds support for the additional SCSI buses depending on configuration.
Josua - any objection to moving USB boot before SCSI in the priority order?
I'll rebase the series on current master since it will conflict, but wanted to try to get consensus on the approach before doing so.
Okay from me for this.
Thanks, Stefan
Looking again it looks like *both* were merged and resulted in some duplication, I just sent a related simple patch to correct.
Joel
participants (2)
-
Joel Johnson
-
Stefan Roese