[PATCH v3 5/6] soc: qcom: cmd-db: Allow boot without CMD DB data

[Casey Connolly]

Hi Balaji,

On 16/06/2026 11:22, Balaji Selvanathan wrote:
> In snagboot mode, XBL loads U-Boot directly without populating CMD DB.
> The cmd-db driver fails to bind when CMD DB magic is invalid, blocking
> boot even when CMD DB is not strictly required.
> 
> Add QCOM_COMMAND_DB_OPTIONAL config to allow the driver to bind
> successfully when CMD DB data is absent. When enabled, a warning is
> logged and cmd_db_header is set to NULL, so consumer drivers receive
> errors on resource queries rather than preventing boot entirely.

Since we know we're in snagboot mode, as I mentioned before we don't
need this additional option, just check for CONFIG_QCOM_SNAGBOOT_MODE
instead rather than introduce another footgun.


> 
> Signed-off-by: Balaji Selvanathan <balaji.selvanathan at oss.qualcomm.com>
> ---
> Changes in v3:
> - Used "if (IS_ENABLED(CONFIG_QCOM_COMMAND_DB_OPTIONAL))" instead
>   of #ifdef
> 
> Changes in v2:
> - No changes
> ---
>  drivers/soc/qcom/Kconfig  | 18 ++++++++++++++++++
>  drivers/soc/qcom/cmd-db.c | 14 ++++++++++++--
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 8243805e46a..7f4cf1b9a98 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -18,6 +18,24 @@ config QCOM_COMMAND_DB
>  	  resource on a RPM-hardened platform must use this database to get
>  	  SoC specific identifier and information for the shared resources.
>  
> +config QCOM_COMMAND_DB_OPTIONAL
> +	bool "Allow operation without Command DB data"
> +	depends on QCOM_COMMAND_DB
> +	help
> +	  Allow the Command DB driver to bind successfully even when CMD DB
> +	  data is not populated or has an invalid magic number.
> +
> +	  This is useful for platforms where CMD DB is not populated by the
> +	  previous bootloader (e.g., snagboot mode where XBL loads U-Boot
> +	  directly without initializing CMD DB).
> +
> +	  When enabled, missing CMD DB will generate warnings but allow boot
> +	  to continue. Consumer drivers must handle cmd_db API failures
> +	  gracefully by checking return values.
> +
> +	  If unsure, say N. Most production Qualcomm platforms require
> +	  valid CMD DB data.
> +
>  config QCOM_RPMH
>  	bool "Qualcomm RPMh support"
>  	depends on QCOM_COMMAND_DB
> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
> index d0a6047b8a6..9b5091f5b5a 100644
> --- a/drivers/soc/qcom/cmd-db.c
> +++ b/drivers/soc/qcom/cmd-db.c
> @@ -252,8 +252,18 @@ static int cmd_db_bind(struct udevice *dev)
>  
>  	cmd_db_header = base;
>  	if (!cmd_db_magic_matches(cmd_db_header)) {
> -		log_err("%s: Invalid Command DB Magic\n", __func__);
> -		return -EINVAL;
> +		if (IS_ENABLED(CONFIG_QCOM_COMMAND_DB_OPTIONAL)) {
> +			log_warning("%s: CMD DB magic not found (0x%02x%02x%02x%02x)\n",
> +				    __func__, cmd_db_header->magic[0], cmd_db_header->magic[1],
> +				    cmd_db_header->magic[2], cmd_db_header->magic[3]);
> +			log_warning("%s: CMD DB data unavailable, resource queries will fail\n",
> +				    __func__);

You can drop these warnings if snagboot mode is enabled since that's the
expected case. I think it would be more appropriate to log a warning if
snagboot is enabled and we DO have a valid cmd-db, since that isn't an
expected usecase right?

Kind regards,

> +			cmd_db_header = NULL;
> +			return 0;
> +		} else {
> +			log_err("%s: Invalid Command DB Magic\n", __func__);
> +			return -EINVAL;
> +		}
>  	}
>  
>  	return 0;
> 

-- 
// Casey (she/her)