Re: [PATCH] accel/qaic: Add Sahara implementation for firmware loading

2024-04-12 Thread Jeffrey Hugo

On 3/21/2024 9:49 PM, Jeffrey Hugo wrote:

The AIC100 secondary bootloader uses the Sahara protocol for two
purposes - loading the runtime firmware images from the host, and
offloading crashdumps to the host. The crashdump functionality is only
invoked when the AIC100 device encounters a crash and dumps are enabled.
Also the collection of the dump is optional - the host can reject
collecting the dump.

The Sahara protocol contains many features and modes including firmware
upload, crashdump download, and client commands. For simplicity,
implement the parts of the protocol needed for loading firmware to the
device.

Fundamentally, the Sahara protocol is an embedded file transfer
protocol. Both sides negotiate a connection through a simple exchange of
hello messages. After handshaking through a hello message, the device
either sends a message requesting images, or a message advertising the
memory dump available for the host. For image transfer, the remote device
issues a read data request that provides an image (by ID), an offset, and
a length. The host has an internal mapping of image IDs to filenames. The
host is expected to access the image and transfer the requested chunk to
the device. The device can issue additional read requests, or signal that
it has consumed enough data from this image with an end of image message.
The host confirms the end of image, and the device can proceed with
another image by starting over with the hello exchange again.

Some images may be optional, and only provided as part of a provisioning
flow. The host is not aware of this information, and thus should report
an error to the device when an image is not available. The device will
evaluate if the image is required or not, and take the appropriate
action.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Carl Vanderlip 
Reviewed-by: Pranjal Ramajor Asha Kanojiya 


Pushed to drm-misc-next

-Jeff


Re: [PATCH] accel/qaic: Add Sahara implementation for firmware loading

2024-04-08 Thread Jacek Lawrynowicz
Reviewed-by: Jacek Lawrynowicz 

On 22.03.2024 04:49, Jeffrey Hugo wrote:
> The AIC100 secondary bootloader uses the Sahara protocol for two
> purposes - loading the runtime firmware images from the host, and
> offloading crashdumps to the host. The crashdump functionality is only
> invoked when the AIC100 device encounters a crash and dumps are enabled.
> Also the collection of the dump is optional - the host can reject
> collecting the dump.
> 
> The Sahara protocol contains many features and modes including firmware
> upload, crashdump download, and client commands. For simplicity,
> implement the parts of the protocol needed for loading firmware to the
> device.
> 
> Fundamentally, the Sahara protocol is an embedded file transfer
> protocol. Both sides negotiate a connection through a simple exchange of
> hello messages. After handshaking through a hello message, the device
> either sends a message requesting images, or a message advertising the
> memory dump available for the host. For image transfer, the remote device
> issues a read data request that provides an image (by ID), an offset, and
> a length. The host has an internal mapping of image IDs to filenames. The
> host is expected to access the image and transfer the requested chunk to
> the device. The device can issue additional read requests, or signal that
> it has consumed enough data from this image with an end of image message.
> The host confirms the end of image, and the device can proceed with
> another image by starting over with the hello exchange again.
> 
> Some images may be optional, and only provided as part of a provisioning
> flow. The host is not aware of this information, and thus should report
> an error to the device when an image is not available. The device will
> evaluate if the image is required or not, and take the appropriate
> action.
> 
> Signed-off-by: Jeffrey Hugo 
> Reviewed-by: Carl Vanderlip 
> Reviewed-by: Pranjal Ramajor Asha Kanojiya 
> ---
> 
>  drivers/accel/qaic/Makefile   |   3 +-
>  drivers/accel/qaic/qaic_drv.c |  10 +
>  drivers/accel/qaic/sahara.c   | 450 ++
>  drivers/accel/qaic/sahara.h   |  10 +
>  4 files changed, 472 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/accel/qaic/sahara.c
>  create mode 100644 drivers/accel/qaic/sahara.h
> 
> diff --git a/drivers/accel/qaic/Makefile b/drivers/accel/qaic/Makefile
> index 3f7f6dfde7f2..df02c1c0d6a6 100644
> --- a/drivers/accel/qaic/Makefile
> +++ b/drivers/accel/qaic/Makefile
> @@ -10,4 +10,5 @@ qaic-y := \
>   qaic_control.o \
>   qaic_data.o \
>   qaic_drv.o \
> - qaic_timesync.o
> + qaic_timesync.o \
> + sahara.o
> diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c
> index d1a632dbaec6..ccfbac88c724 100644
> --- a/drivers/accel/qaic/qaic_drv.c
> +++ b/drivers/accel/qaic/qaic_drv.c
> @@ -29,6 +29,7 @@
>  #include "mhi_controller.h"
>  #include "qaic.h"
>  #include "qaic_timesync.h"
> +#include "sahara.h"
>  
>  MODULE_IMPORT_NS(DMA_BUF);
>  
> @@ -635,12 +636,20 @@ static int __init qaic_init(void)
>   goto free_pci;
>   }
>  
> + ret = sahara_register();
> + if (ret) {
> + pr_debug("qaic: sahara_register failed %d\n", ret);
> + goto free_mhi;
> + }
> +
>   ret = qaic_timesync_init();
>   if (ret)
>   pr_debug("qaic: qaic_timesync_init failed %d\n", ret);
>  
>   return 0;
>  
> +free_mhi:
> + mhi_driver_unregister(_mhi_driver);
>  free_pci:
>   pci_unregister_driver(_pci_driver);
>   return ret;
> @@ -665,6 +674,7 @@ static void __exit qaic_exit(void)
>*/
>   link_up = true;
>   qaic_timesync_deinit();
> + sahara_unregister();
>   mhi_driver_unregister(_mhi_driver);
>   pci_unregister_driver(_pci_driver);
>  }
> diff --git a/drivers/accel/qaic/sahara.c b/drivers/accel/qaic/sahara.c
> new file mode 100644
> index ..d5da8e166998
> --- /dev/null
> +++ b/drivers/accel/qaic/sahara.c
> @@ -0,0 +1,450 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +/* Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. 
> */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sahara.h"
> +
> +#define SAHARA_HELLO_CMD 0x1  /* Min protocol version 1.0 */
> +#define SAHARA_HELLO_RESP_CMD0x2  /* Min protocol version 
> 1.0 */
> +#define SAHARA_READ_DATA_CMD 0x3  /* Min protocol version 1.0 */
> +#define SAHARA_END_OF_IMAGE_CMD  0x4  /* Min protocol version 
> 1.0 */
> +#define SAHARA_DONE_CMD  0x5  /* Min protocol version 
> 1.0 */
> +#define SAHARA_DONE_RESP_CMD 0x6  /* Min protocol version 1.0 */
> +#define SAHARA_RESET_CMD 0x7  /* Min protocol version 1.0 */
> +#define SAHARA_RESET_RESP_CMD0x8  /* Min protocol version 
> 1.0 */
> +#define 

Re: [PATCH] accel/qaic: Add Sahara implementation for firmware loading

2024-03-22 Thread Bjorn Andersson
On Thu, Mar 21, 2024 at 09:49:17PM -0600, Jeffrey Hugo wrote:
> The AIC100 secondary bootloader uses the Sahara protocol for two
> purposes - loading the runtime firmware images from the host, and
> offloading crashdumps to the host. The crashdump functionality is only
> invoked when the AIC100 device encounters a crash and dumps are enabled.
> Also the collection of the dump is optional - the host can reject
> collecting the dump.
> 
> The Sahara protocol contains many features and modes including firmware
> upload, crashdump download, and client commands. For simplicity,
> implement the parts of the protocol needed for loading firmware to the
> device.
> 
> Fundamentally, the Sahara protocol is an embedded file transfer
> protocol. Both sides negotiate a connection through a simple exchange of
> hello messages. After handshaking through a hello message, the device
> either sends a message requesting images, or a message advertising the
> memory dump available for the host. For image transfer, the remote device
> issues a read data request that provides an image (by ID), an offset, and
> a length. The host has an internal mapping of image IDs to filenames. The
> host is expected to access the image and transfer the requested chunk to
> the device. The device can issue additional read requests, or signal that
> it has consumed enough data from this image with an end of image message.
> The host confirms the end of image, and the device can proceed with
> another image by starting over with the hello exchange again.
> 
> Some images may be optional, and only provided as part of a provisioning
> flow. The host is not aware of this information, and thus should report
> an error to the device when an image is not available. The device will
> evaluate if the image is required or not, and take the appropriate
> action.
> 
> Signed-off-by: Jeffrey Hugo 
> Reviewed-by: Carl Vanderlip 
> Reviewed-by: Pranjal Ramajor Asha Kanojiya 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn