Skip to content
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

boards: add Myra SiP Baseboard #79706

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

fkokosinski
Copy link
Member

@fkokosinski fkokosinski commented Oct 11, 2024

This PR:

  • adds driver for the mb85rsm1t fram
  • adds support for a new SoC in Zephyr - Myra SiP
  • adds a new target that is based on the Myra SiP - Myra SiP Baseboard

Copy link
Collaborator

Choose a reason for hiding this comment

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

Convert to webp, then put through https://tinypng.com/

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, filesize went down from 93k -> 34k

Supported Features
------------------

The Zephyr ``myra_sip_baseboard`` board configuration supports the following hardware features:
Copy link
Collaborator

Choose a reason for hiding this comment

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

*board target

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

soc/antmicro/myra/Kconfig.soc Show resolved Hide resolved
Copy link
Collaborator

@nordicjm nordicjm left a comment

Choose a reason for hiding this comment

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

More I think about it the more it is a no, this is an stm32 with supporting components, they go in the board dts, do not create a "soc sip", use the existing stm32 one. This is no different than e.g. rm1xx_dvk where there is an spi flash inside the module

@kgugala
Copy link
Collaborator

kgugala commented Oct 11, 2024

Hi @nordicjm, thanks for your comment.

More I think about it the more it is a no, this is an stm32 with supporting components, they go in the board dts, do not create a "soc sip", use the existing stm32 one

This approach would mean that the shared configuration between board targets that share the same SiP would have to include duplicated code that would be otherwise provided by the SiP symbol, though.

Additionally, there already are other SIPs defined in a similar way in Zephyr, e.g.:

  • soc/nordic/nrf91/Kconfig.soc:
    • CONFIG_SOC_NRF9161_LACA
  • soc/nordic/nrf92/Kconfig.soc:
    • CONFIG_SOC_NRF9280
  • soc/espressif/esp32s2/Kconfig.soc:
    • CONFIG_SOC_ESP32S2_SOLO_N* (4 types)
    • CONFIG_SOC_ESP32S2_MINI* (2 types)
    • CONFIG_SOC_ESP32S2_WROOM
    • CONFIG_SOC_ESP32S2_WROVER* (3 types)
  • soc/espressif/esp32s3/Kconfig.soc:
    • CONFIG_SOC_ESP32S3_MINI* (2 types)
    • CONFIG_SOC_ESP32S3_WROOM* (9 types)

For now, all the SIPs in supported in Zephyr are produced by the same vendor as the main SoC used in the SIP, however this is not always a case in the real world. Another example (similar to Myra) of such a SIP is https://octavosystems.com/octavo_products/osd32mp15x/ (this one is not yet supported in Zephyr, but we plan to add it soon)

@nordicjm
Copy link
Collaborator

The 91* and 92* are normal SoCs in tree so I don't see what you mean. The espressif ones are different chips with different internal configurations, this one you have here is just a specific stm32 chip with peripherals around it, there is no reason to do it as you've done it here. Not that SiP's aren't important and support for that in hwmv2 is planned for the future, but there is nothing groundbreaking here that cannot be done as every other "SiP" in zephyr is done with a normal SoC definition for the actual SoC and then anything inside of a "package" being done at board level

@fkokosinski
Copy link
Member Author

The 91* and 92* are normal SoCs in tree so I don't see what you mean

Those nRFs mentioned by @kgugala are referred to as SiPs by comments in their respective Kconfigs. As for CONFIG_SOC_NRF9161_LACA, the comment is here: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nordic/nrf91/Kconfig.soc#L31-L3

Plus, on the vendor's site nRF9161 is also explicitly called a SiP: https://www.nordicsemi.com/Products/nRF9161.

The nRF9161 is technically a SiP (System-in-Package) that consists of the nRF9120 SoC and additional components like PMIC, FEM, and XTAL, so for nrfx/MDK the nRF9120 SoC is to be indicated as the build target, but since the nRF9161 is what a user can actually see on a board, using only nRF9120 in the Zephyr build infrastructure might be confusing. That's why in the top level of SoC definitions (for user-configurable options in Kconfig, for example) the nRF9161 term is used and nRF9120 underneath.

And as for CONFIG_SOC_NRF9280, the comment is present here: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nordic/nrf92/Kconfig.soc#L37

The SiP selects the actual SoC complete with engineer revision and appropriate CPU

Additionally, this file also states the following: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nordic/nrf92/Kconfig.soc#L12-L14

Like it's done for the nRF91 family, let the nRF9280 SiP be represented by nRF9280 "SoC" in top-level SoC definitions and user-configurable Kconfigs, since that's what visible to users.

Which means that those nRFs are explicitly defined as SiPs, and are definitely not "normal" SoCs.


The espressif ones are different chips with different internal configurations

Again, those ESPs that Karol had mentioned are listed under the "SiP" section comment in their respective Kconfig files:

SiP with flash and/or psram


but there is nothing groundbreaking here that cannot be done as every other "SiP" in zephyr is done with a normal SoC definition for the actual SoC and then anything inside of a "package" being done at board level

That's not exactly true, which the examples above prove. I.e. CONFIG_SOC_NRF9161_LACA (which is a Kconfig symbol for a SiP), selects CONFIG_SOC_NRF9120. I fail to see how nRF9161 is more "worthy" of being allowed this chain of Kconfig symbols as opposed to Myra, which other than having the STM32G491REI6 MCU in it, also integrates a 128kB FRAM chip, FTDI FT231XQ, crystal oscillators, LDOs etc. See more here: https://designer.antmicro.com/hardware/devices/myra-sip-interposer.

And here's the Kconfig snippet which demonstrates the Kconfig symbol chain: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nordic/nrf91/Kconfig.soc#L31-L41.

In summary: this PR doesn't really introduce any new way of defining a SiP; it just chooses the exact same convention that Zephyr had already opted to use.

Copy link
Member

@henrikbrixandersen henrikbrixandersen left a comment

Choose a reason for hiding this comment

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

adds driver for the mb85rsm1t fram
adds support for a new SoC in Zephyr - Myra SiP
adds a new target that is based on the Myra SiP - Myra SiP Baseboard

This needs to be split into at least two PRs: One for adding the Myra SiP support along with the baseboard, and another for adding the EEPROM driver (unless the EEPROM driver is needed for the board to boot, but it does not look like it is?).

@fkokosinski
Copy link
Member Author

but it does not look like it is?

Correct - it's not needed for basic operation of the board. I've removed the driver from this PR.

Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Dec 22, 2024
MAINTAINERS.yml Outdated
Comment on lines 132 to 133
- fkokosinski
- kgugala
- tgorochowik
Copy link
Collaborator

Choose a reason for hiding this comment

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

2 maintainers should be plenty. Please make whoever is the 3rd name a collaborator

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@@ -0,0 +1,5 @@
board:
name: myra_sip_baseboard
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
name: myra_sip_baseboard
name: myra_sip_baseboard
full_name: Myra SiP Baseboard

Copy link
Member Author

Choose a reason for hiding this comment

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

Added full name

Comment on lines 1 to 4
.. _myra_sip_baseboard:

Myra SiP Baseboard
########################
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
.. _myra_sip_baseboard:
Myra SiP Baseboard
########################
.. zephyr:board:: myra_sip_baseboard

Copy link
Member Author

Choose a reason for hiding this comment

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

the new directive is now used in the board doc

Comment on lines 30 to 33
.. image:: img/myra_sip_baseboard.webp
:align: center
:alt: Myra SiP Baseboard

Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
.. image:: img/myra_sip_baseboard.webp
:align: center
:alt: Myra SiP Baseboard

zephyr:board:: directive automagically adds the image

Copy link
Member Author

Choose a reason for hiding this comment

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

removed

Programming and Debugging
*************************

Applications for the ``myra_sip_baseboard`` board configuration can be built and flashed in the usual way (see :ref:`build_an_application` and :ref:`application_run` for more details).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Applications for the ``myra_sip_baseboard`` board configuration can be built and flashed in the usual way (see :ref:`build_an_application` and :ref:`application_run` for more details).
Applications for the ``myra_sip_baseboard`` board target can be built and flashed in the usual way (see :ref:`build_an_application` and :ref:`application_run` for more details).

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

toolchain:
- zephyr
- gnuarmemb
- xtools
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- xtools

Copy link
Member Author

Choose a reason for hiding this comment

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

removed xtools from the list

@github-actions github-actions bot removed the Stale label Dec 24, 2024
@fkokosinski fkokosinski requested a review from kartben January 7, 2025 11:47
@decsny decsny removed their request for review January 7, 2025 15:52
tejlmand
tejlmand previously approved these changes Jan 8, 2025
Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

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

Approving.

There's currently no clean concepts of SiPs in Zephyr, but HWMV2 has paved the way to improve this by offering a better and more scalable model.
But for now, SiPs are generally exposed as being a SoC.

I think the current suggestion of presenting the Myra SiP with it's own SoC name in the soc / board yaml and Kconfig is acceptable as the system is for now.
I also believe it will make it less intrusive when having a true SiP support, as the names / symbols in that case will not need to change (assumption 🙈 ).

Having dedicated SiP Kconfig symbol selecting the true STM SOC also allows to different cases where it's important to distinguish the SiP from the SoC.

CONFIG_UART_CONSOLE=y
CONFIG_ARM_MPU=y
CONFIG_HW_STACK_PROTECTION=y
CONFIG_MAIN_STACK_SIZE=4096
Copy link
Collaborator

@nordicjm nordicjm Jan 9, 2025

Choose a reason for hiding this comment

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

why is this needed? (main stack size, not the rest)

Comment on lines 13 to 15
CONFIG_RTC=y
CONFIG_RTC_STM32=y
CONFIG_RTC_LOG_LEVEL_WRN=y
Copy link
Collaborator

Choose a reason for hiding this comment

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

why is RTC needed for every single build e.g. hello world?

wasilewskiJ and others added 2 commits January 10, 2025 13:39
Add support for the Antmicro's Myra SiP Baseboard. The board uses
Antmicro's Myra SiP which integrates STM32G491XX MCU and its SoC
configuration.

Signed-off-by: Jakub Wasilewski <[email protected]>
Signed-off-by: Filip Kokosinski <[email protected]>
This commit adds the `Antmicro platforms` area of maintenance.

Signed-off-by: Filip Kokosinski <[email protected]>
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.

9 participants