Skip to content

boards: opta: external flash and BLE support #90264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 27, 2025

Conversation

fogzot
Copy link
Contributor

@fogzot fogzot commented May 21, 2025

This set of changes adds support for QSPI-based external flash and Bluetooth to the device tree. This make it possible to correctly build and execute the fatfs and several Bluetooth samples out of the box.

Also added a function to read the external flash OTP to extract information about the Opta model and hardware features and a second function to retrieve the "official" Opta serial number.

Copy link
Collaborator

@pillo79 pillo79 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! There was actually another PR adding initial Flash support to Opta so I waited for that to get in before reviewing this one.
Please rebase and fix the conflicts, mostly LGTM except for the security read operation - to be accepted it should be reworked so it is implemented by the Flash driver.

@pillo79 pillo79 self-assigned this May 23, 2025
@fogzot
Copy link
Contributor Author

fogzot commented May 26, 2025

Thanks for this! There was actually another PR adding initial Flash support to Opta so I waited for that to get in before reviewing this one.
Please rebase and fix the conflicts, mostly LGTM except for the security read operation - to be accepted it should be reworked so it is implemented by the Flash driver.

I see some small differences between the current quadspi definition and mine:

  1. bus width is set to 2 but the ST quadspi supports 4 without problems;
  2. maximum frequency is 70 MHz while the datasheet specifies 80 MHz.

It is OK to keep my values or there is indication that Zephyr needs the current values?

Copy link
Collaborator

@pillo79 pillo79 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see some small differences between the current quadspi definition and mine:

  1. bus width is set to 2 but the ST quadspi supports 4 without problems;

  2. maximum frequency is 70 MHz while the datasheet specifies 80 MHz.

It is OK to keep my values or there is indication that Zephyr needs the current values?

Yes, please use your values - Opta should have no issues supporting 4 lanes and 80MHz clocks.

@de-nordic de-nordic removed their assignment Jun 3, 2025
fogzot added a commit to dndg/zephyr that referenced this pull request Jun 6, 2025
Some external flash modules have extra commands to support, for example,
reading/writing an OTP zone. Given that the commands are highly specific
and difficult to generalize, we add two ex ops that can be used to
transmit a custom command (in the form of a full QSPI_CommandTypeDef) and
then read or write a user-provided buffer.

As a reference here is the link to the discussion where one of the
reviewers asked for using ex ops instead of custom code in a board.c file.

Link: zephyrproject-rtos#90264

Signed-off-by: Federico Di Gregorio <[email protected]>
fogzot added a commit to dndg/zephyr that referenced this pull request Jun 6, 2025
Some external flash modules have extra commands to support, for example,
reading/writing an OTP zone. Given that the commands are highly specific
and difficult to generalize, we add two ex ops that can be used to
transmit a custom command (in the form of a full QSPI_CommandTypeDef) and
then read or write a user-provided buffer.

As a reference here is the link to the discussion where one of the
reviewers asked for using ex ops instead of custom code in a board.c file.

Link: zephyrproject-rtos#90264

Signed-off-by: Federico Di Gregorio <[email protected]>
@fogzot
Copy link
Contributor Author

fogzot commented Jun 20, 2025

I think the last push addresses al open issues.

@fogzot fogzot requested a review from pillo79 June 20, 2025 14:37
pillo79
pillo79 previously approved these changes Jun 20, 2025
Copy link
Collaborator

@etienne-lms etienne-lms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments, otherwise LGTM.

#define AT25SF128_READ_SECURITY_REGISTERS 0x48

static struct opta_board_info opta_board_info = {0};
static char serial_number[OPTA_SERIAL_NUMBER_SIZE + 1] = {0};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{0} initializer is not needed in the 2 lines above.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was fact actually useful for the serial number, since the very first call to opta_get_serial_number is expecting to find a zero-filled buffer (and return a zero-terminated string):

if (serial_number[0] == 0) {
uint32tohex(&serial_number[0], HAL_GetUIDw0());
uint32tohex(&serial_number[8], HAL_GetUIDw1());
uint32tohex(&serial_number[16], HAL_GetUIDw2());
}
return serial_number;

Please restore this to ensure proper operation, otherwise LGTM!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading @etienne-lms comment I tought that statics where automatically zeroed. If they are not then the initialization is necessary. I'll revert the change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They should be unless I missed something. Static variables are expected to fall in the BSS section if not initialized, and in the data section if initialized.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, my bad, forgot that actually are zero initialized already. Sorry for the misdirection! 🤦‍♂️

@fogzot
Copy link
Contributor Author

fogzot commented Jun 25, 2025

@etienne-lms I just pushed all requested changes.

etienne-lms
etienne-lms previously approved these changes Jun 25, 2025
Copy link
Collaborator

@etienne-lms etienne-lms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with comment addressed or not.

Comment on lines 45 to 46
int ret = flash_ex_op(dev, FLASH_STM32_QSPI_EX_OP_GENERIC_READ, (uintptr_t)&cmd,
&opta_board_info);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking suggestion:

	return flash_ex_op(dev, FLASH_STM32_QSPI_EX_OP_GENERIC_READ, (uintptr_t)&cmd,
			   &opta_board_info);

Comment on lines 166 to 168
qspi_flash: qspi-nor-flash@90000000 {
compatible = "st,stm32-qspi-nor";
reg = <0>;
reg = <0x90000000 DT_SIZE_M(16)>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to account for #89942

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I was not aware of the change so I just use the definition I knew worked. I just fixed this.

@fogzot fogzot force-pushed the opta branch 2 times, most recently from 51bde72 to 74ecb86 Compare June 27, 2025 10:28
This set of changes adds support for QSPI-based external flash and
Bluetooth to the device tree. This make it possible to correctly build and
execute the fatfs and several Bluetooth samples out of the box.

Also added a function to read the external flash OTP to extract
information about the Opta model and hardware features and a second
function to retrieve the "official" Opta serial number.

Signed-off-by: Federico Di Gregorio <[email protected]>
Copy link

@danieldegrasse danieldegrasse merged commit 2221072 into zephyrproject-rtos:main Jun 27, 2025
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants