SIM3U: board + UART #64209

M1cha · 2023-10-21T06:45:27Z

This is a reduced version of #57871.
I removed everything that is not needed for UART. I've also added documentation and rebased to the latest main branch. I didn't address much(if anything) from the original PR to make differences more visible.

zephyrbot · 2023-10-21T06:46:36Z

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_silabs	zephyrproject-rtos/hal_silabs@`d191d98` (master)	zephyrproject-rtos/hal_silabs#29	zephyrproject-rtos/hal_silabs#29/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

fkokosinski · 2023-10-23T08:32:58Z

drivers/gpio/gpio_si32.c

+#define GPIO_DEVICE_INIT_SI32(__suffix)                                                            \
+	GPIO_DEVICE_INIT(DT_NODELABEL(gpio##__suffix), __suffix,                                   \
+			 DT_REG_ADDR(DT_NODELABEL(gpio##__suffix)))
+
+#if DT_NODE_HAS_STATUS(DT_NODELABEL(gpio0), okay)
+GPIO_DEVICE_INIT_SI32(0);
+#endif
+
+#if DT_NODE_HAS_STATUS(DT_NODELABEL(gpio1), okay)
+GPIO_DEVICE_INIT_SI32(1);
+#endif
+
+#if DT_NODE_HAS_STATUS(DT_NODELABEL(gpio2), okay)
+GPIO_DEVICE_INIT_SI32(2);
+#endif
+
+#if DT_NODE_HAS_STATUS(DT_NODELABEL(gpio3), okay)
+GPIO_DEVICE_INIT_SI32(3);
+#endif


Can we use DT_INST_FOREACH_STATUS_OKAY instead of hardcoding instance numbers here?

you're right. I copied that from another driver which didn't use that either at the time. Right now, the only driver left that doesn't use that macro seems to be stm32.

fkokosinski · 2023-10-23T08:44:29Z

soc/arm/silabs_sim3/sim3u/soc.c

+static void vmon_init(void)
+{
+	/* VMON must be enabled for flash write/erase support */
+
+	NVIC_ClearPendingIRQ(VDDLOW_IRQn);
+
+	IRQ_CONNECT(VDDLOW_IRQn, 0, vddlow_irq_handler, NULL, 0);
+	irq_enable(VDDLOW_IRQn);
+
+	SI32_VMON_A_enable_vdd_supply_monitor(SI32_VMON_0);
+	SI32_VMON_A_enable_vdd_low_interrupt(SI32_VMON_0);
+	SI32_VMON_A_select_vdd_standard_threshold(SI32_VMON_0);
+}


Is flash support required for UART operation? As per the PR description

IMO we should convert this to a separate sensor driver

Your post ends mid-sentence and these lines don't have anything related to flash, but: The flash driver itself is not needed for UART, but:

I couldn't find a way to compile without it due to zephyr using flash nodes to figure out how to link the binary

Changing the AHB clock speed requires changing a FLASHCTRL register: https://github.com/zephyrproject-rtos/zephyr/pull/64209/files/861b3c678668d5157c6ba8384a156c0e036fd678#diff-2e890857b384cfc0e5d42940be13fd38adc48f1acc2d3c260f44d3f1db14ffafR86

Definitely, It's just that we didn't have a use for it yet and this is only needed to enable the watchdog. I'll have to look into how well this hardware fits into the sensor subsystem and how much work it'd be to integrate it.

don't have anything related to flash

What about /* VMON must be enabled for flash write/erase support */?

Oh sry, I forgot about that. I put this here because it's required to read/write flash and I assumed that everyone would want this (which may not be true ofc).

I don't think the sensor subsystem is a good fit for VMON because this hardware can only produce notifications in form of interrupts, you can't read the voltage level(it's not an ADC). It also seems to be wired up to other peripherals internally. My assumption is that the flash silicon wants to prevent write write-operation failures by detecting VDD issues.

fkokosinski · 2023-10-23T08:45:20Z

soc/arm/silabs_sim3/sim3u/soc.c

+	/* Apply pinctrl gpio settings */
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_0, PORTBANK_0_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_0, PORTBANK_0_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_0, PORTBANK_0_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_0, PORTBANK_0_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_0, PORTBANK_0_PINS_ANALOG);
+
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_1, PORTBANK_1_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_1, PORTBANK_1_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_1, PORTBANK_1_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_1, PORTBANK_1_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_1, PORTBANK_1_PINS_ANALOG);
+
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_2, PORTBANK_2_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_2, PORTBANK_2_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_2, PORTBANK_2_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_2, PORTBANK_2_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_2, PORTBANK_2_PINS_ANALOG);
+
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_3, PORTBANK_3_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_3, PORTBANK_3_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_3, PORTBANK_3_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_3, PORTBANK_3_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_3, PORTBANK_3_PINS_ANALOG);


Shouldn't this be handled by the pinctrl driver then?

We don't have a pinctrl driver. That's the reason why this exists in first place. The GPIO driver shouldn't be used here either since it must be set even if CONFIG_GPIO is disabled.

why is this code put here and not in a pinctrl driver? can you please explain why can't this be executed by each driver?

A device driver usually informs the pinctrl subsystem about the pinconfig it wants by calling pinctrl_apply_state. After that function returns it expect things to be muxed already and may start using the device.

So what we need to do on sim3u is to know which pinmuxings are needed before even trying to probe every driver.

Of course, we could just cache the request in "pinctrl_apply_state" but not actually apply any changes, then register a SYS_INIT at a very late level like APPLICATION where we apply it. But IMO that would violate the pinctrl API and may not work with certain drivers.

IMO the pinctrl API is just fundamentally incompatible with the way sim3u works and I was simply trying to find a way to at least be able to use the expressiveness provided by the devicetree nodes.

fkokosinski · 2023-10-23T08:46:00Z

soc/arm/silabs_sim3/sim3u/soc.c

+	/* Enable misc clocks.
+	 * We may or may nor need all of that but it includes some basics like
+	 * LOCK0, WDTIMER0 and DMA. Doing it here prevents the actual drivers
+	 * needing to know whoelse needs one of these clocks.
+	 */
+	SI32_CLKCTRL_A_enable_apb_to_modules_1(
+		SI32_CLKCTRL_0, SI32_CLKCTRL_A_APBCLKG1_MISC0 | SI32_CLKCTRL_A_APBCLKG1_MISC1);
+	SI32_CLKCTRL_A_enable_ahb_to_dma_controller(SI32_CLKCTRL_0);


Could we read which clocks we need from the devicetree?

How exactly would that look like? The proper way would probably be to have e driver+device for every clock and then pass it via devicetree and create a custom driver interface to turn the clock handle into a register for apb.

To me that seems like a lot of additional code and overhead for something that we currently don't support changing anyway.

fkokosinski · 2023-10-23T08:47:00Z

soc/arm/silabs_sim3/sim3u/soc.h

+
+#ifndef _SOC__H_
+#define _SOC__H_
+


I know that in some cases on some architectures Zephyr requires an soc.h header, even if it's empty. Just wanted to make sure that it is the case here as well.

zephyr/modules/cmsis/cmsis_core_m.h seems to need it.

fkokosinski · 2023-10-23T08:47:34Z

west.yml

@@ -222,7 +222,7 @@ manifest:
      groups:
        - hal
    - name: hal_silabs
-      revision: d191d981c4eb20c0c7445a4061fcdbcfa686113a
+      revision: 98b458d99b74083fce4c715fedcee45d388eb8b8


You should point to the PR head directly, i.e. revision: pull/x/head where x is your PR number in the HAL.

good idea, thx

fkokosinski · 2023-10-23T08:48:04Z

soc/arm/silabs_sim3/sim3u/soc.c

+
+	/* Since a hardware reset affects the debug hardware as well, this
+	 * makes it easier to recover from a broken firmware */
+	busy_delay(3000000);


Can we use k_busy_wait here?

k_busy_wait uses a hardware counter and I didn't think it was a good idea to rely on it's availability at this early stage. If you understand those better and can confirm that it's not an issue I can change it though.

fkokosinski · 2023-10-23T08:49:33Z

soc/arm/silabs_sim3/sim3u/soc.c

+
+	key = irq_lock();
+
+	/* The watchdog may be enabled already so we have to disable it */


Enabled by whom - is there some kind of bootrom on this SoC that enables some of the peripherals? What's the default reset state for watchdog on SIM3U?

Unfortunately I don't know that. It's just something that I have observed to be the case on certain devices.

rettichschnidi

Thanks a lot! I have not (yet) compiled/tested this code, only found some typos while skimming the PR.

rettichschnidi · 2023-10-23T08:55:14Z

boards/arm/gardena_rm_sim3u/doc/index.rst

@@ -0,0 +1,71 @@
+.. _boardname_linkname:
+
+GARDENA SIM3U radio module


Suggested change

GARDENA SIM3U radio module

GARDENA SiM3U radio module

rettichschnidi · 2023-10-23T08:55:35Z

boards/arm/gardena_rm_sim3u/doc/index.rst

+
+.. figure:: gardena_rm_sim3u.jpg
+   :align: center
+   :alt: GARDENA SIM3U radio module


Suggested change

:alt: GARDENA SIM3U radio module

:alt: GARDENA SiM3U radio module

rettichschnidi · 2023-10-23T08:58:05Z

boards/arm/gardena_rm_sim3u/doc/index.rst

+Hardware
+********
+
+- SIM3U167B-GM SoC


According to the data sheet:

Suggested change

- SIM3U167B-GM SoC

- SiM3U167-B-GM SoC

rettichschnidi · 2023-10-23T08:58:41Z

boards/arm/gardena_rm_sim3u/doc/index.rst

+********
+
+- SIM3U167B-GM SoC
+- SPI si4467 transceiver


Suggested change

- SPI si4467 transceiver

- SPI Silicon Labs Si4467 transceiver

rettichschnidi · 2023-10-23T08:59:12Z

boards/arm/gardena_rm_sim3u/doc/index.rst

+========
+
+The easiest way is to do this via SSH from the Linux SoM that's connected to
+the SIM3U SoM.


Suggested change

the SIM3U SoM.

the SiM3U SoM.

rettichschnidi · 2023-10-23T09:02:06Z

boards/arm/gardena_rm_sim3u/gardena_rm_sim3u.dts

+#include "gardena_rm_sim3u-pinctrl.dtsi"
+
+/ {
+	model = "GARDENA sim3u radio module";


Suggested change

model = "GARDENA sim3u radio module";

model = "GARDENA Sim3U radio module";

rettichschnidi · 2023-10-23T09:02:28Z

boards/arm/gardena_rm_sim3u/gardena_rm_sim3u.yaml

+# SPDX-License-Identifier: Apache-2.0
+
+identifier: gardena_rm_sim3u
+name: GARDENA sim3u radio module


Suggested change

name: GARDENA sim3u radio module

name: GARDENA SiM3U radio module

rettichschnidi · 2023-10-23T09:04:05Z

soc/arm/silabs_sim3/sim3u/Kconfig.defconfig.series

@@ -0,0 +1,23 @@
+# SIM3U series configuration options


Suggested change

# SIM3U series configuration options

# SiM3U series configuration options

rettichschnidi · 2023-10-23T09:04:45Z

soc/arm/silabs_sim3/sim3u/Kconfig.defconfig.series

+	default "sim3u"
+
+config SOC_PART_NUMBER
+	default "SIM3U167-A-GM" if SOC_PART_NUMBER_SIM3U167_A_GM


I am not understand why exactly this is needed, but there seems to be no A variant:

Suggested change

default "SIM3U167-A-GM" if SOC_PART_NUMBER_SIM3U167_A_GM

default "SiM3U167-B-GM" if SOC_PART_NUMBER_SIM3U167_B_GM

Seems to be a way for boards to select the variant in case that information is needed at compile-time. But you're right so I switched it to the B variant which is also selected by our board.

rettichschnidi · 2023-10-23T09:13:18Z

soc/arm/silabs_sim3/sim3u/gen_crossbar_config.py

+
+"""Generate crossbar register values from devicetree pinctrl nodes.
+
+The sim3u soc does support pinmuxing, but with many limimitations.


Suggested change

The sim3u soc does support pinmuxing, but with many limimitations.

The SiM3U soc does support pinmuxing, but with many limimitations.

gmarull · 2023-10-23T10:53:25Z

soc/arm/silabs_sim3/sim3u/gen_crossbar_config.py

+class Signal(enum.Enum):
+    USART0_TX = 0
+    USART0_RX = 1
+    USART0_RTS = 2
+    USART0_CTS = 3
+    USART0_UCLK = 4
+
+    USART1_TX = 9


can you please explain why we need pinctrl related Python scripts in soc/? If this is required by the HAL, -1 to have this in tree.

This is described in detail in the documentation of said python module: https://github.com/zephyrproject-rtos/zephyr/pull/64209/files#diff-0a14224d1df8e0d15ef02b23405ccca2fa3ee71eb65671d7c03b289357a112beR7

This is a workaround due to hardware limitations. The pinctrl hardware functions under the assumption that you set all the configs once at boot and never touch them again. This doesn't fit zephyrs pinctrl subsystem which tries to configure pins for every peripheral on demand, one by one. The python script allows using devicetree pinctrl nodes to simplify pin configuration even though we do not support the pinctrl subsystem.

can you please provide a datasheet or something to look at?

https://www.silabs.com/documents/public/data-sheets/SiM3U1xx-SiM3C1xx-RM.pdf
8. Port I/O Configuration, Specifically the crossbar descriptions.

I guess it's

When configuring the crossbar, all settings should be made to the crossbar and Port Bank registers before
enabling the crossbar. This ensures that peripherals will not shift around while each one is being enabled and Port
I/O pins will remain stable. The settings in PBOUTMD, PBMDSEL, or PBSKIPEN will not take effect until the
crossbars are enabled.

right?

gmarull · 2023-10-23T10:53:47Z

soc/arm/silabs_sim3/sim3u/soc.c

+	/* Apply pinctrl gpio settings */
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_0, PORTBANK_0_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_0, PORTBANK_0_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_0, PORTBANK_0_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_0, PORTBANK_0_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_0, PORTBANK_0_PINS_ANALOG);
+
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_1, PORTBANK_1_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_1, PORTBANK_1_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_1, PORTBANK_1_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_1, PORTBANK_1_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_1, PORTBANK_1_PINS_ANALOG);
+
+	SI32_PBSTD_A_write_pins_high(SI32_PBSTD_2, PORTBANK_2_PINS_HIGH);
+	SI32_PBSTD_A_write_pins_low(SI32_PBSTD_2, PORTBANK_2_PINS_LOW);
+	SI32_PBSTD_A_set_pins_digital_input(SI32_PBSTD_2, PORTBANK_2_PINS_DIGITAL_INPUT);
+	SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_2, PORTBANK_2_PINS_PUSH_PULL_OUTPUT);
+	SI32_PBSTD_A_set_pins_analog(SI32_PBSTD_2, PORTBANK_2_PINS_ANALOG);


-1 on custom pin control mechanisms.

can you expand on what you mean by "custom"? Are you referring to #64209 (comment) ? Any comments on my reply to that?

This bumps the hal_silabs in order to add initial support for sim3u SoCs. WIP, because the revision wasn't merged, yet. Signed-off-by: Michael Zimmermann <[email protected]>

Includes the SoC, pinctrl, flash and devicetree. I had to include the flash driver that early because I couldn't make zephyr compile without flash driver nodes in the device tree. Signed-off-by: Michael Zimmermann <[email protected]>

this serves two main purposes: - change the CPU clock via devicetree nodes - provide the APB frequency to device drivers via the clock driver interface Theoretically this could also support choosing between the available clock sources, but right now we only support LPOSC0 going into PLL0, going into AHB. Turning the PLL back off is also not supported since the only current usecase is to set the PLL frequency, turn it on, and switch the AHB over to it. Signed-off-by: Michael Zimmermann <[email protected]>

This is just the driver for banks 0,1,2,3. Bank 4 will come via a separate commit since it needs a different driver. Signed-off-by: Michael Zimmermann <[email protected]>

This supports polling and interrupt APIs, but not the async API. Signed-off-by: Michael Zimmermann <[email protected]>

Signed-off-by: Michael Zimmermann <[email protected]>

M1cha · 2023-11-10T09:43:10Z

I rebased, fixed typos and made the gpio driver use foreach. Most comments are still waiting for feedback.

gmarull

after explanation, pinctrl changes look reasonable, thanks for the details. added a few more comments

gmarull · 2023-11-13T09:58:32Z

soc/arm/silabs_sim3/sim3u/soc.c

+	SI32_VMON_A_select_vdd_standard_threshold(SI32_VMON_0);
+}
+
+__no_optimization static void busy_delay(uint32_t cycles)


please use k_busy_wait

#64209 (comment)

gmarull · 2023-11-13T09:59:08Z

soc/arm/silabs_sim3/sim3u/soc.c

+static void gpio_init(void)
+{
+	/* Enable clocks that we need in any case */
+	SI32_CLKCTRL_A_enable_apb_to_modules_0(
+		SI32_CLKCTRL_0, SI32_CLKCTRL_A_APBCLKG0_PB0 | SI32_CLKCTRL_A_APBCLKG0_FLASHCTRL0);
+
+	/* Enable misc clocks.
+	 * We may or may nor need all of that but it includes some basics like
+	 * LOCK0, WDTIMER0 and DMA. Doing it here prevents the actual drivers
+	 * needing to know whoelse needs one of these clocks.
+	 */
+	SI32_CLKCTRL_A_enable_apb_to_modules_1(


please split all the pinctrl functionality into its own commit, and explain why this is done this way

Do we expect explanations to be available in multiple places? While I obviously find good commit messages important, I prefer to put documentation that is important for the code in general rather than the specific change into the code. That's why I wrote a very lengthy explanation in the python script documentation.

the Python script is ok, this function should probably have a couple of lines that it works thanks to such script. an individual commit message adding the crossbar functionality will also help (e.g. commit message summarizing details and referencing to the datasheet relevant sections)

Do you know of any ways to split up Initial sim3u1xx support? That commit contains everything that's needed for just UART. I wasn't even able to separate the flash driver - let alone the crossbar config.

just add bits that build but do not work as a whole, this has been done many times in Zephyr, e.g. first add bindings, then driver using them

gmarull · 2023-11-13T10:00:11Z

soc/arm/silabs_sim3/sim3u/CMakeLists.txt

+
+zephyr_sources(soc.c)
+
+set(CROSSBAR_CONFIG_H ${CMAKE_BINARY_DIR}/zephyr/include/generated/silabs_crossbar_config.h)


this is being refactored now to include zephyr/ prefix #63973

rettichschnidi · 2023-12-07T00:16:09Z

boards/arm/gardena_rm_sim3u/gardena_rm_sim3u.dts

+
+		slot0_partition: partition@0 {
+			label = "image-0";
+			reg = <0x00000000 DT_SIZE_K(1664)>;


1664 kilobytes?

Suggested change

reg = <0x00000000 DT_SIZE_K(1664)>;

reg = <0x00000000 DT_SIZE_K(192)>;

rettichschnidi · 2023-12-07T00:16:40Z

boards/arm/gardena_rm_sim3u/gardena_rm_sim3u.dts

+			reg = <0x00000000 DT_SIZE_K(1664)>;
+		};
+
+		storage_partition: partition@250000 {


Reflecting the actual offset would be better I guess?

Suggested change

storage_partition: partition@250000 {

storage_partition: partition@30000 {

github-actions · 2024-02-05T00:29:40Z

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.

rettichschnidi · 2024-02-05T18:40:48Z

Please do not close. @M1cha let me know if you'd rather have me taking this over, would be happy do to so.

nordicjm

Needs to be migrated to hwmv2

github-actions · 2024-04-27T00:29:50Z

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.

rettichschnidi · 2024-04-27T04:26:33Z

This is still being worked in (https://github.com/husqvarnagroup/zephyr/tree/gardena/rs/sim3u). Please do not close.

stale

This is cherry-picked from the PR already opened by Michael Zimmermann: zephyrproject-rtos#57871 Eventually, this commit should be updated with the new PR posted here: zephyrproject-rtos#64209 For this reason, do not merge substantial improvements over the original PR into this commit - it would (likely) be forgotten when switching to the new PR. Note: As requested by the reviewers upstream, the new PR is reduced in scope and therefore, the extracted parts need to be brought back manually. (cherry picked from commit a2ce87510b7ee119f3df179192ffb5ff083b6100) (squashed ab4505ff0d234c457aaa0d3ddc27833157d0d0ad)

github-actions · 2024-06-29T00:29:50Z

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.

M1cha requested review from nashif, carlescufi, galak, MaureenHelm, mnkp, de-nordic and ioannisg as code owners October 21, 2023 06:45

zephyrbot added area: Pinctrl area: GPIO area: UART Universal Asynchronous Receiver-Transmitter platform: Silabs Silicon Labs area: Flash area: Devicetree Binding PR modifies or adds a Device Tree binding area: Clock Control labels Oct 21, 2023

zephyrbot requested review from dcpleung, fkokosinski, gmarull, henrikbrixandersen, nordic-krch, tgorochowik and yonsch October 21, 2023 06:46

zephyrbot assigned nordic-krch Oct 21, 2023

M1cha mentioned this pull request Oct 21, 2023

SIM3U support #57871

Closed

zephyrbot added manifest manifest-hal_silabs labels Oct 21, 2023

fkokosinski previously requested changes Oct 23, 2023

View reviewed changes

rettichschnidi reviewed Oct 23, 2023

View reviewed changes

gmarull requested changes Oct 23, 2023

View reviewed changes

WIP: west.yml: hal_silabs: update hal version

f6d61a7

This bumps the hal_silabs in order to add initial support for sim3u SoCs. WIP, because the revision wasn't merged, yet. Signed-off-by: Michael Zimmermann <[email protected]>

M1cha added 5 commits November 10, 2023 10:39

Initial sim3u1xx support

353b789

Includes the SoC, pinctrl, flash and devicetree. I had to include the flash driver that early because I couldn't make zephyr compile without flash driver nodes in the device tree. Signed-off-by: Michael Zimmermann <[email protected]>

sim3u: add gpio driver

fa53491

This is just the driver for banks 0,1,2,3. Bank 4 will come via a separate commit since it needs a different driver. Signed-off-by: Michael Zimmermann <[email protected]>

sim3u: add usart driver

cea8a8d

This supports polling and interrupt APIs, but not the async API. Signed-off-by: Michael Zimmermann <[email protected]>

add gardena_rm_sim3u

6a108cd

Signed-off-by: Michael Zimmermann <[email protected]>

M1cha force-pushed the sim3u-uart branch from 861b3c6 to 6a108cd Compare November 10, 2023 09:42

zephyrbot added the DNM This PR should not be merged (Do Not Merge) label Nov 10, 2023

gmarull requested changes Nov 13, 2023

View reviewed changes

rettichschnidi requested changes Dec 7, 2023

View reviewed changes

github-actions bot added the Stale label Feb 5, 2024

henrikbrixandersen removed the Stale label Feb 5, 2024

nordicjm requested changes Feb 26, 2024

View reviewed changes

rettichschnidi mentioned this pull request Apr 25, 2024

soc: silabs: Facilitate non-Gecko SoC support #71938

Merged

github-actions bot added the Stale label Apr 27, 2024

github-actions bot removed the Stale label Apr 28, 2024

github-actions bot added the Stale label Jun 29, 2024

github-actions bot closed this Jul 13, 2024

rettichschnidi mentioned this pull request Aug 4, 2024

Add initial Silabs SiM3U support #76677

Merged

3 tasks


		key = irq_lock();

		/* The watchdog may be enabled already so we have to disable it */

		@@ -0,0 +1,71 @@
		.. _boardname_linkname:

		GARDENA SIM3U radio module

	:alt: GARDENA SIM3U radio module
	:alt: GARDENA SiM3U radio module

	- SPI si4467 transceiver
	- SPI Silicon Labs Si4467 transceiver

	model = "GARDENA sim3u radio module";
	model = "GARDENA Sim3U radio module";

	name: GARDENA sim3u radio module
	name: GARDENA SiM3U radio module

	# SIM3U series configuration options
	# SiM3U series configuration options

	default "SIM3U167-A-GM" if SOC_PART_NUMBER_SIM3U167_A_GM
	default "SiM3U167-B-GM" if SOC_PART_NUMBER_SIM3U167_B_GM


		"""Generate crossbar register values from devicetree pinctrl nodes.

		The sim3u soc does support pinmuxing, but with many limimitations.


		zephyr_sources(soc.c)

		set(CROSSBAR_CONFIG_H ${CMAKE_BINARY_DIR}/zephyr/include/generated/silabs_crossbar_config.h)


		#ifndef _SOC__H_
		#define _SOC__H_

	reg = <0x00000000 DT_SIZE_K(1664)>;
	reg = <0x00000000 DT_SIZE_K(192)>;

	storage_partition: partition@250000 {
	storage_partition: partition@30000 {

SIM3U: board + UART #64209

SIM3U: board + UART #64209

Conversation

M1cha commented Oct 21, 2023

zephyrbot commented Oct 21, 2023 • edited Loading

Choose a reason for hiding this comment

M1cha Nov 10, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

M1cha Oct 23, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

M1cha Nov 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rettichschnidi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

M1cha Oct 23, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

M1cha commented Nov 10, 2023

gmarull left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

M1cha Nov 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Feb 5, 2024

rettichschnidi commented Feb 5, 2024

nordicjm left a comment

Choose a reason for hiding this comment

github-actions bot commented Apr 27, 2024

rettichschnidi commented Apr 27, 2024

github-actions bot commented Jun 29, 2024

zephyrbot commented Oct 21, 2023 •

edited

Loading

M1cha Nov 10, 2023 •

edited

Loading

M1cha Oct 23, 2023 •

edited

Loading

M1cha Nov 13, 2023 •

edited

Loading

M1cha Oct 23, 2023 •

edited

Loading

M1cha Nov 13, 2023 •

edited

Loading