Re: [PATCH v2 0/3] Add Firmware Upload support for beagleplay cc1352

From: Jason Kridner
Date: Wed Jul 31 2024 - 15:44:35 EST


Ayush,

Thanks so much for jumping on this so quickly and getting it out to
the kernel list for public discussion. Sorry I missed commenting on
v1. Great work so far!

On Wed, Jul 31, 2024 at 2:53 PM Ayush Singh <ayush@xxxxxxxxxxxxxxx> wrote:
>
> Adds support for beagleplay cc1352 co-processor firmware upgrade using
> kernel Firmware Upload API. Uses ROM based bootloader present in
> cc13x2x7 and cc26x2x7 platforms for flashing over UART.
>
> Communication with the bootloader can be moved out of gb-beagleplay
> driver if required, but I am keeping it here since there are no
> immediate plans to use the on-board cc1352p7 for anything other than
> greybus (BeagleConnect Technology). Additionally, there do not seem to
> any other devices using cc1352p7 or it's cousins as a co-processor.

s/it's/its/

While I'm not aware of other Linux boards that have integrated
CC1352P7, there are other interesting software stacks that could be
run, like:
* zStack[1] for Zigbee,
* wpanusb/bcfserial[2] for IEEE 802.15.4g,
* ti-wisunfantund[3] for WiSun, or
* OTBR[4][5] for OpenThread

It feels to me like there should be a cc13x2x7/cc26x2x7 driver that
also exposes a serdev device that can be used as either a tty for
direct interaction with the firmware or by another driver like
gb-greybus. While supporting these others in the upstream kernel isn't
in the immediate plans, I think it would be best to clear the path for
the drivers to specify the firmware they want. Ideally, the firmware
required by gb-greybus would be in the linux-firmware repository and
could be requested by the driver itself out of /lib/firmware and
attempting to load multiple cc1352-dependant drivers would
appropriately conflict and therefore present useful errors and not
load, unless a system had additional cc1352 devices to which they
could connect.

>
> Bootloader backdoor and Reset GPIOs are used to enable cc1352p7 bootloader

s/Reset/reset/

> backdoor for flashing. Flashing is skipped in case we are trying to flash
> the same image as the one that is currently present. This is determined by
> CRC32 calculation of the supplied firmware and Flash data.

s/Flash/flash/

>
> We also do a CRC32 check after flashing to ensure that the firmware was
> flashed properly.
>
> Link: https://www.ti.com/lit/ug/swcu192/swcu192.pdf Ti CC1352p7 Tecnical Specification

s/CC1352p7/CC1352P7/
s/Tecnical/Technical/

> Link:
> https://lore.kernel.org/all/20240719-beagleplay_fw_upgrade-v1-0-8664d4513252@xxxxxxxxxxxxxxx/
> Patch v1
>
> Changes in v2:
> - Spelling fixes
> - Rename boot-gpios to bootloader-backdoor-gpios
> - Add doc comments
> - Add check to ensure firmware size is 704 KB
>
> Signed-off-by: Ayush Singh <ayush@xxxxxxxxxxxxxxx>
> ---
> Ayush Singh (3):
> dt-bindings: net: ti,cc1352p7: Add bootloader-backdoor-gpios
> arm64: dts: ti: k3-am625-beagleplay: Add bootloader-backdoor-gpios to cc1352p7
> greybus: gb-beagleplay: Add firmware upload API
>
> .../devicetree/bindings/net/ti,cc1352p7.yaml | 7 +
> arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 3 +-
> drivers/greybus/Kconfig | 1 +
> drivers/greybus/gb-beagleplay.c | 658 ++++++++++++++++++++-
> 4 files changed, 655 insertions(+), 14 deletions(-)
> ---
> base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7
> change-id: 20240715-beagleplay_fw_upgrade-43e6cceb0d3d
>
> Best regards,
> --
> Ayush Singh <ayush@xxxxxxxxxxxxxxx>
>

[1] https://www.zigbee2mqtt.io/guide/adapters/zstack.html
[2] https://openbeagle.org/beagleplay/bcfserial
[3] https://github.com/TexasInstruments/ti-wisunfantund
[4] https://openthread.io/guides/border-router
[5] https://github.com/openthread/ot-cc13x2-cc26x2

--
BeagleBoard.org Foundation is a US-based 501(c)3 non-profit providing
education and collaboration around open source hardware and software

Use https://beagleboard.org/about/jkridner to schedule a meeting