boards: qualcomm: Add QCC744M EVK

[VynDragon]

I thought it was a good time to be Qualcomm's Upstream first.

There is no acceptable ways to flash the board without large engineering efforts, so simple instructions on how to do it are provided in the board's documentation. Beside the flash operation, it works the same as other BL61x boards.

[VynDragon]

How do i deal with the binary file thing? It's configuration (boot header) in binary format...

[josuah]

For blobs: https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

What I understood:

• They need to be hosted on a 3rd-party repo/http server rather than in anything from Zephyr
• Normal PR, no TSC approval required
• Example of HAL repo that contains a blob: https://github.com/zephyrproject-rtos/hal_renesas/tree/main/zephyr
• Example of PRs introducing a blob: Adding dave2d driver support on lvgl for Renesas RA devices #97163

module.yml inside the HAL:

name: hal_renesas
build:
  cmake: .
blobs:
  # libcmac
  - path: smartbond/cmac/libcmac/libcmac.a
    sha256: 3d7fcb880a0a2d635e333ff6eb131a17acf466ec7b19947a7d3ea1ebfb68ab1b
    type: lib
    version: '1.2'
    license-path: zephyr/blobs/license.txt
    url: https://github.com/dialog-semiconductor/CMAC-library/raw/main/libcmac.a
    description: "Binary libraries with firmware for CMAC controller"
    doc-url: https://github.com/dialog-semiconductor/CMAC-library

There is no hal_qualcomm, but this could be seen as a Bouffalo Lab artifact published by Qualcomm, just like Renesas publishes a file from Dialog Semi.

[VynDragon]

making it draft until i figure a better way to flash.

[josuah]

In drivers, #define SENSORXXX_ABC 0x3313 contains the "binary blob" 0x3313 which is manufacturer-provided data used at init time. Sometimes very big chunks and not much documented:

zephyr/drivers/video/imx335.c

Lines 96 to 165 in 545d40e

	static const struct video_reg16 imx335_fixed_regs[] = {
	{0x3288, 0x21},
	{0x328a, 0x02},
	{0x3414, 0x05},
	{0x3416, 0x18},
	{0x3648, 0x01},
	{0x364a, 0x04},
	{0x364c, 0x04},
	{0x3678, 0x01},
	{0x367c, 0x31},
	{0x367e, 0x31},
	{0x3706, 0x10},
	{0x3708, 0x03},
	{0x3714, 0x02},
	{0x3715, 0x02},
	{0x3716, 0x01},
	{0x3717, 0x03},
	{0x371c, 0x3d},
	{0x371d, 0x3f},
	{0x372c, 0x00},
	{0x372d, 0x00},
	{0x372e, 0x46},
	{0x372f, 0x00},
	{0x3730, 0x89},
	{0x3731, 0x00},
	{0x3732, 0x08},
	{0x3733, 0x01},
	{0x3734, 0xfe},
	{0x3735, 0x05},
	{0x3740, 0x02},
	{0x375d, 0x00},
	{0x375e, 0x00},
	{0x375f, 0x11},
	{0x3760, 0x01},
	{0x3768, 0x1b},
	{0x3769, 0x1b},
	{0x376a, 0x1b},
	{0x376b, 0x1b},
	{0x376c, 0x1a},
	{0x376d, 0x17},
	{0x376e, 0x0f},
	{0x3776, 0x00},
	{0x3777, 0x00},
	{0x3778, 0x46},
	{0x3779, 0x00},
	{0x377a, 0x89},
	{0x377b, 0x00},
	{0x377c, 0x08},
	{0x377d, 0x01},
	{0x377e, 0x23},
	{0x377f, 0x02},
	{0x3780, 0xd9},
	{0x3781, 0x03},
	{0x3782, 0xf5},
	{0x3783, 0x06},
	{0x3784, 0xa5},
	{0x3788, 0x0f},
	{0x378a, 0xd9},
	{0x378b, 0x03},
	{0x378c, 0xeb},
	{0x378d, 0x05},
	{0x378e, 0x87},
	{0x378f, 0x06},
	{0x3790, 0xf5},
	{0x3792, 0x43},
	{0x3794, 0x7a},
	{0x3796, 0xa1},
	{0x37b0, 0x36},
	{0x3a00, 0x01},
	};

Not too different from here. It could work to have that as an annotated C array, comments generated from the python source above?

If so, I can try that.

[VynDragon]

I mean yea, there can be a script to generate the bin at build time, however it still requires to use the qualcomm tool or devcube, or bflb-iot-tool, instead of the one we have a runner for, so might as well just tell the user to get the header from the sdk, except that might not be acceptable...

[JarmouniA]

In drivers, #define SENSORXXX_ABC 0x3313 contains the "binary blob" 0x3313 which is manufacturer-provided data used at init time..... Not too different from here

It is, sensor vs SoC

[VynDragon]

Removed any blob thing, provided instructions instead.

[josuah]

It is, sensor vs SoC

True! I thought about the same approach as drivers: decode every byte with a #define until no magic number is left. Or even a __packed struct.
A workaround was found though. :)

[VynDragon]

There's no 'magic' really, it's just that doing the whole ops would require a lot of stuffs to get around...
encode.py
parse.py
out.json

[josuah]

Looking at the porting guide, I could not find anything missing. Thanks!

[mbolivar]

Hi there! I'm surprised and happy to see this board getting some attention in upstream zephyr. I would like to ask that this not be merged until we have time to get our ducks in a row internally as it would be our first upstream board, and a lot of times the first decisions made have a way of lasting a long time.

Thank you again for your contribution and I will be in touch as soon as possible.

[VynDragon]

Hello, it's been on the bflb roadmap (#83663) for quite a long time and with the recent announcements by Qualcomm I thought there was a unique occasion.

Anyway, I have been trying to get in contact with qcom about this serie since I was made aware of it, and have a lot of questions, so feel free to contact all of us from the bouffalolab port.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mbolivar]

feel free to contact all of us from the bouffalolab port.

@VynDragon are you responsible for the BL port? I'd love some more details if so :)

[VynDragon]

Yea, mostly. I am adding you to a discord group with the active bflb port contributors for discussing.

[filzek]

The QCC744M looking to the board, the USB at the left side, to set it in flashable mode you need to press the buton on top release and press the button on botton and relase, so you can flash using the windows or by manual command prompt. There is the SDK in codelinaro and in the vscode, so you can take a look at the flash using the vscode ide and reproduce the steps inside the zephyr

[VynDragon]

The QCC744M looking to the board, the USB at the left side, to set it in flashable mode you need to press the buton on top release and press the button on botton and relase, so you can flash using the windows or by manual command prompt. There is the SDK in codelinaro and in the vscode, so you can take a look at the flash using the vscode ide and reproduce the steps inside the zephyr

I am not sure what you are trying to say, we have been successful in flashing zephyr to the board using the tooling provided, and also by tweaking the usual tooling slightly. The issue is there is no practical way to do this easily with the current everything. The SDK tooling doesnt actually do a full flash btw, it only copies the header by copying the boot2 loader, while the usual tooling (bflb-mcu-tool-uart) generates a new header before flashing and appends the firmware to it.