Use picolibc instead of newlib-nano #134

keith-packard · 2025-05-19T22:56:10Z

 1. Add picolibc bits to linker scripts. Picolibc uses thread local storage
    for unshared data, and the picolibc startup code relies on carefully
    constructed linker script that allocates one TLS block in RAM for
    applications that don't have explicit TLS support. The picolibc
    startup code also uses different symbols than the tf-m startup code.

 2. Support picolibc stdio. There was already picolibc support code
    present in the library for the ARM LLVM toolchain. The
    conditionals which selected it have been changed to use
    __PICOLIBC__ instead of __clang_major__.

 3. Add _exit stub. Code using assert or abort end up calling _exit
    through the picolibc signal handling code.

 4. Switch to picolibc.specs. This is needed for toolchains which
    don't use picolibc by default, and can also be used without
    trouble in toolchains where picolibc is the default.

keith-packard · 2025-07-28T02:11:03Z

These are (finally) passing Zephyr tests using both SDK 0.17 and SDK 0.18-alpha4 (although each requires some additional changes which are wending their way upstream). I think they're ready for review and help getting them upstream.

tomi-font · 2025-07-28T11:46:11Z

platform/ext/common/gcc/tfm_common_s.ld.template

+    /* Reset current position for subsequent sections */
+    . = LOADADDR(.ER_CODE_SRAM) + SIZEOF(.ER_CODE_SRAM);


How did the linker get confused exactly? Is this really needed?

. got set to LOADADDR instead of ADDR when building with binutils 2.43. I'm afraid that after spending several hours chasing this down, I didn't dig into the linker code to figure out precisely why that happened.

I've re-added this patch as it is necessary even with SDK 0.17.4.

tomi-font

Had a chat with upstream about these (picolibc) changes. Let's keep them only in this fork until they're not needed anymore (TF-M is moving away from C library usage), in the next release or the one following it.
But it would be good to have someone who understands this a bit to review the changes. Don't know who that could be. cc @frkv @d3zd3z @ceolin @dleach02 @Vge0rge

keith-packard · 2025-07-28T15:59:59Z

Had a chat with upstream about these (picolibc) changes. Let's keep them only in this fork until they're not needed anymore (TF-M is moving away from C library usage), in the next release or the one following it. But it would be good to have someone who understands this a bit to review the changes. Don't know who that could be. cc @frkv @d3zd3z @ceolin @dleach02 @Vge0rge

Sounds good. I'll keep running tests as this series moves forward. This is not buildable using SDK 0.17.2 because of a last-minute oops in that release, but it should be buildable with the upcoming SDK 0.17.3.

frkv · 2025-07-29T05:45:11Z

I recommend @wearyzen and @adeaarm give it a quick look from TF-M's perspective.

The Clang/LLVM toolchain for TF-M was added with no dependency on libc and/or picolib in the core TF-M code, but you still see references to nano.specs in the GNUARM toolchain

Zephyr, making this choice for GNUARM toolchain (this change), will take any penalty related to support, any security advisories etc... But the choice to go to picolibc is an active choice in the Zephyr community, and in extension it will impact any vendor who makes use of standard c library function in PSA crypto and PSA crypto driver build as well as in bootloaders...

With regards to these commits, I think we should consider them to be marked as commits emitted from zephyr integration, unless they are possible to add upstream in the TF-M project... If they are out-of-tree patches required for Zephyr integration, they would need to be maintained across updated versions of TF-M in our fork

tomi-font · 2025-07-29T09:28:49Z

With regards to these commits, I think we should consider them to be marked as commits emitted from zephyr integration

Yeah this is something we've agreed on and I think just needs to be implemented (documenting the practice basically). In the meantime I don't think we can require that of anyone yet.

Anton-TF · 2025-07-29T16:12:19Z

True, TF-M plans to remove libc from all secure binaries (BL1, BL2, tfm_s) for Clang/LLVM and GCC toolchains at least.
As part of this effort, we also intend to clean up and streamline the linker scripts.

Additionally, you might want to consider these recent fixes in the scripts:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40014
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40068

keith-packard · 2025-07-29T18:09:21Z

Sounds like any libc-specific changes will be transient then, which will be nice.

This adds linker script bits and compiler options so that trusted-firmware-m will build with picolibc. This has not been merged to the Zephyr trusted-firmware-m repository yet, that PR is zephyrproject-rtos/trusted-firmware-m#134 Signed-off-by: Keith Packard <keithp@keithp.com>

This adds linker script bits and compiler options so that trusted-firmware-m will build with picolibc. This has not been merged to the Zephyr trusted-firmware-m repository yet: zephyrproject-rtos/trusted-firmware-m#134 Signed-off-by: Keith Packard <keithp@keithp.com>

wearyzen · 2025-08-28T20:13:34Z

While trying to build the non-secure MPS4 board with this PR and Zephyr SDK 0.18.0-alpha4 we see below error:

west build -p -b mps4/corstone320/fvp/ns samples/hello_world/ -t run
...
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: (.text._start+0x30): undefined reference to `__data_source'
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: (.text._start+0x34): undefined reference to `__data_start'
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: (.text._start+0x38): undefined reference to `__bss_size'
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: (.text._start+0x3c): undefined reference to `__bss_start'
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: (.text._start+0x40): undefined reference to `__tls_base'
/home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld: /home/zephyr-sdk-0.18.0-alpha4/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/space/libc.a(libc_picolib_machine_arm_set_tls.c.o): in function `_set_tls':
set_tls.c:(.text._set_tls+0xc): undefined reference to `__arm32_tls_tcb_offset'

Referring to the changes in this PR, I tried below patch and it seems to fix the issue:

git diff
diff --git a/bl1/bl1_2/bl1_dummy_rotpk.prv b/bl1/bl1_2/bl1_dummy_rotpk.prv
index bf011cd4d..b6bf9b600 100644
Binary files a/bl1/bl1_2/bl1_dummy_rotpk.prv and b/bl1/bl1_2/bl1_dummy_rotpk.prv differ
diff --git a/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_1.ld b/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_1.ld
index 44f04021a..7fad80960 100644
--- a/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_1.ld
+++ b/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_1.ld
@@ -160,6 +160,25 @@ SECTIONS
     } > RAM

     bss_size = __bss_end__ - __bss_start__;
+    /* --- add after the .bss section --- */
+    PROVIDE( __bss_start = __bss_start__ );
+    PROVIDE( __bss_end   = __bss_end__ );
+    PROVIDE( __bss_size  = __bss_end - __bss_start );
+
+    PROVIDE( __data_start  = ADDR(.data) );
+    PROVIDE( __data_end    = __data_end__ );
+    PROVIDE( __data_source = LOADADDR(.data) );
+    PROVIDE( __data_size   = __data_end - __data_start );
+
+    /* BL1_1 doesn’t use TLS, but picolibc’s _set_tls needs these present */
+    PROVIDE( __tls_base = 0 );
+    PROVIDE( __tls_align = 8 );
+    PROVIDE( __arm32_tls_tcb_offset = 8 );
+
+    /* --- add after the .heap section (where __HeapBase/Limit are set) --- */
+    PROVIDE( __heap_start = __HeapBase );
+    PROVIDE( __heap_end   = __HeapLimit );
+

 #if defined (__ARM_FEATURE_CMSE) && (__ARM_FEATURE_CMSE == 3U)
     .msp_stack (NOLOAD) : ALIGN(32)
diff --git a/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_2.ld b/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_2.ld
index 83aaf144f..9151ff3a0 100644
--- a/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_2.ld
+++ b/platform/ext/target/arm/mps4/common/device/source/gcc/mps4_corstone3xx_bl1_2.ld
@@ -162,6 +162,25 @@ SECTIONS

     bss_size = __bss_end__ - __bss_start__;

+    /* --- add after the .bss section --- */
+    PROVIDE( __bss_start = __bss_start__ );
+    PROVIDE( __bss_end   = __bss_end__ );
+    PROVIDE( __bss_size  = __bss_end - __bss_start );
+
+    PROVIDE( __data_start  = ADDR(.data) );
+    PROVIDE( __data_end    = __data_end__ );
+    PROVIDE( __data_source = LOADADDR(.data) );
+    PROVIDE( __data_size   = __data_end - __data_start );
+
+    /* BL1_1 doesn’t use TLS, but picolibc’s _set_tls needs these present */
+    PROVIDE( __tls_base = 0 );
+    PROVIDE( __tls_align = 8 );
+    PROVIDE( __arm32_tls_tcb_offset = 8 );
+
+    /* --- add after the .heap section (where __HeapBase/Limit are set) --- */
+    PROVIDE( __heap_start = __HeapBase );
+    PROVIDE( __heap_end   = __HeapLimit );
+
 #if defined (__ARM_FEATURE_CMSE) && (__ARM_FEATURE_CMSE == 3U)
     .msp_stack (NOLOAD) : ALIGN(32)
     {
(END)

I am not a linker script expert but if above change looks good then please let me know if you would like to include it in this PR.
Thanks!

Vge0rge · 2025-11-03T09:31:23Z

D

Thanks again for the fix @keith-packard . I can now confirm that this patch works for Nordic devices :)
Feel free to rework the history and let me know when you are done so that I can approve this.

Just pushed a rebase -i that cleans up the sequence a bit and should work through bisect, but the result is exactly the same as what you've already tested (at least according to git diff?)

Small suggestion, it would be nice in my opinion to include tags like the one used in mbedtls fork of Zephyr (https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/README.md) when you do the rewrite. I am not gonna block the PR for this since this is not an official rule in this repo yet but I am just suggesting it.

Sure, happy to tag these with [zep noup] as we're expecting upstream to drop libc entirely, making this whole sequence unnecessary.

Edit: I ended up approving so that I don't NACK you anymore. If you rewrite it will anyway request my review again.

Thanks. Really appreciate your help getting this over the line. I'm looking forward to having SDK 1.0 fully supported by Zephyr 4.3, even if it won't be the "official" toolchain.

Diff looks good to me as well :) Thanks for adding the tags and for the support as well. Glad to see that moving forward!

JarmouniA · 2025-11-03T10:51:35Z

Cc @etienne-lms @ahmadstm

etienne-lms

I've successfully tested on the few supported STM32 platforms.

For info, while a couple of hundred bytes are saved in flash and RAM when using picolib, I also saw that BL2 footprint was increased by more than 2kByte of flash when console traces are enabled. Observed (from build tests) on various platforms, not only the STM32 ones.

etienne-lms · 2025-10-27T15:23:34Z

platform/ext/common/picolibc.c

@@ -0,0 +1,48 @@
+/*
+ * Copyright © 2025, Keith Packard <keithp@keithp.com>


Prefer ASCII char only? (replace © with (C))

(C) is meaningless. I'll just delete the ©

keith-packard · 2025-11-04T17:49:23Z

For info, while a couple of hundred bytes are saved in flash and RAM when using picolib, I also saw that BL2 footprint was increased by more than 2kByte of flash when console traces are enabled. Observed (from build tests) on various platforms, not only the STM32 ones.

What are console traces and how are they enabled? There's nothing obvious in the source tree that I could find.

If this ends up enabling 'assert' macros, then that can cause a pretty significant jump in flash usage as the default picolibc assert behavior includes __FILE__, __LINE__ and also the asserting expression as a string. Zephyr SDK 1.0 changes that default to remove that information, so asserts no longer cause significant increases in flash usage.

I just reviewed the picolibc code and there's no easy way to disable the verbose assert behavior once enabled. If you want to do this, you'd need to do:

/* make sure the library defaults are loaded */
#include <stdlib.h>
/* unset any default for __ASSERT_VERBOSE */
#undef __ASSERT_VERBOSE
/* get the quiet version of assert defined */
#include <assert.h>

d3zd3z

Overall, I think this is a reasonable, and hopefully temporary workaround. As mentioned, TF-M is trying to move away from libc, so we probably can't upstream this. It is kind of frustrating how dependent this is on the SDK, but I'm not sure that can be avoided.

d3zd3z · 2025-11-11T15:17:55Z

platform/ext/common/picolibc.c

+void
+_start(void)
+{
+  typedef struct __copy_table {


The rest of TF-M seems to use 4 spaces for indentation, and this should probably match that.

In TF-M, the feature will be managed by CONFIG_TFM_INCLUDE_STDLIBC (default OFF, preferred).
If you can upstream Picolib for the other case and include ATfE toolchain support (currently supports only OFF), that would be great and much appreciated.

The rest of TF-M seems to use 4 spaces for indentation, and this should probably match that.

Thanks; I'm not sure how this file ended up with 2-space indentation.

In TF-M, the feature will be managed by CONFIG_TFM_INCLUDE_STDLIBC (default OFF, preferred). If you can upstream Picolib for the other case and include ATfE toolchain support (currently supports only OFF), that would be great and much appreciated.

Happy to help out with this; as ATfE already includes picolibc, this should be pretty easy. I'd like to focus on finishing up the Zephyr integration so it can land in time for Zephyr 4.3.0 if possible. With that, Zephyr 4.3 should be buildable using Zephyr SDK 1.0, and might be close to building with ATfE as well.

keith-packard · 2025-11-11T19:45:15Z

Rebased atop current zephyr main branch and re-indented the picolibc.c file using four spaces.

This adds linker script bits and compiler options so that trusted-firmware-m will build with picolibc. This has not been merged to the Zephyr trusted-firmware-m repository yet: zephyrproject-rtos/trusted-firmware-m#134 Signed-off-by: Keith Packard <keithp@keithp.com>

tpambor

LGTM.

I have tested this PR on STM32H573I-DK and works as expected.

[INF] Starting bootloader
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
[INF] Image index: 1, Swap type: none
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
[INF] Image index: 0, Swap type: none
[INF] Bootloader chainload address offset: 0x38000
[INF] Image version: v0.0.0
[INF] Jumping to the first image slot
Booting TF-M v2.2.0+d491c6136
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
[INF][PS] Encryption alg: 0x5500200
[INF][Crypto] Init HW accelerator...
[INF][Crypto] Init HW accelerator... complete.
*** Booting Zephyr OS build v4.3.0-1147-g51131b46e396 ***
TF-M IPC on stm32h573i_dk
The version of the PSA Framework API is 257.
The PSA Crypto service minor version is 1.
Generating 256 bytes of random data:
DD F4 89 1F 0D DF 40 0E D5 7F D1 44 1E 71 48 C9
05 9C 89 05 0F 63 FA B4 FB BA A3 3A 34 8F 54 AF
9A 1D 30 00 BF D5 AB 57 A5 45 B5 8D 9E 14 CC 38
DC 24 04 6D ED DA BA 3B F0 98 D0 A3 65 73 15 E6
EE 1C F0 75 7D D8 6B 9E B8 88 46 15 61 7B 30 E4
8F BB 2A 95 3F 2C EE D9 75 84 2B 0F 7D 14 88 E2
DA 13 10 22 4C FA 1B 73 D9 DE 61 6E 8F 7A 17 91
BC 1E 8D 14 8D C9 5F B7 4C C7 49 05 2C 3B B5 C6
F3 D7 EB 53 BD E2 00 54 E4 8E 4A 4D 84 D9 88 B9
A1 FC 0B D9 47 45 DE D8 D8 EF 0F A0 83 9C 71 9F
35 0E 5E F1 08 63 C6 98 CC 9B 94 29 B1 A4 1A 74
5B CD 21 A8 8B F5 25 74 35 41 61 CD 97 1D 6D 4A
56 7C 44 7D 13 50 11 93 F1 AD 11 50 51 C9 37 8B
8C D8 CE 01 CB 1B BC 9E 39 F5 88 4F 9B 24 70 35
D1 AF 81 91 B1 45 44 03 07 E4 77 7B 99 3C 29 0A
81 AC AB D6 83 26 09 85 BD CD 13 CA 7E E3 D9 DA

tomi-font · 2025-11-28T08:58:39Z

@keith-packard Would you like to get this in? Will this work with both the current SDK and the upcoming one?
@tejlmand @wearyzen Are you fine with the current changes?

keith-packard · 2025-11-28T17:26:48Z

@keith-packard Would you like to get this in?

Yes, I'm waiting for this to finish up the SDK 1.0 integration work in Zephyr.

Will this work with both the current SDK and the upcoming one?

Yes, I've been doing regular A/B testing using SDK 0.17.5 and a version of SDK 1.0 with a couple of additional changes to make it work with current Zephyr (those are integrated into the SDK repo, but aren't in the current SDK 1.0 beta1 version).

keith-packard · 2025-11-28T20:50:51Z

Yes, I've been doing regular A/B testing using SDK 0.17.5 and a version of SDK 1.0 with a couple of additional changes to make it work with current Zephyr (those are integrated into the SDK repo, but aren't in the current SDK 1.0 beta1 version).

With this change rebased atop the current Zephyr version (c2f9edc), I just ran twister -a arm using SDK 1.0 and had no failures in tests and samples using tf-m. I'll run the same using SDK 0.17.5 to verify that also works.

tomi-font · 2025-12-01T08:34:22Z

With this change rebased atop the current Zephyr version (c2f9edc), I just ran twister -a arm using SDK 1.0 and had no failures in tests and samples using tf-m. I'll run the same using SDK 0.17.5 to verify that also works.

Sounds good, let me know when your testing with SDK 0.17.5 is complete and let's just merge this.

keith-packard · 2025-12-01T16:35:36Z

Sounds good, let me know when your testing with SDK 0.17.5 is complete and let's just merge this.

All finished, no issues with 0.17.5 either.

tomi-font · 2025-12-03T09:06:14Z

The default branch of this repository is being changed to zephyr_tf-m_v2.2.2 which will replace main shortly.
Please rebase your branch atop zephyr_tf-m_v2.2.2 and force-push it.
I have already changed your PR's base branch to zephyr_tf-m_v2.2.2.
Also, make sure to follow the new commit guidelines documented here.

When processing the .ER_CODE_SRAM section, the location counter is set to the VMA of that section, so after processing the next section will use that VMA instead of the next available address in the FLASH region. Reset the location counter to the next available FLASH address after processing this section will ensure that any subsequent FLASH data is placed in the correct location. This test fails without this patch: $ west build -p -b lpcxpresso55s69/lpc55s69/cpu0/ns \ samples/synchronization -T sample.kernel.synchronization .../ld: address 0x14003e84 of bin/tfm_s.axf section `.ER_TFM_CODE' is not within region `FLASH' .../ld: address 0x14005c20 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH' .../ld: bin/tfm_s.axf section `.TFM_PSA_ROT_LINKER_DATA' will not fit in region `FLASH' .../ld: address 0x14003e84 of bin/tfm_s.axf section `.ER_TFM_CODE' is not within region `FLASH' .../ld: address 0x14005c20 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH' .../ld: ERROR: CMSE stub (.gnu.sgstubs section) too far (0x10008540) from destination (0x14003ee4) Note that the linker is generating addresses within the CODE_RAM memory region rather than the FLASH region. Signed-off-by: Keith Packard <keithp@keithp.com>

…mplates While the copy table included the default data segment for these templates, the zero table didn't include the default bss segment. Make sure that area gets initialized to zero using the table-based mechanism instead of relying on the startup code to initialize it explicitly. Signed-off-by: Keith Packard <keithp@keithp.com>

…ipts Picolibc uses different names for the list of constructors and heap limits. Add values for __bothinit_array_start, __bothinit_array_end, __heap_start and __heap_end to every linker script. If not using picolibc, these will not have any effect. Signed-off-by: Keith Packard <keithp@keithp.com>

1. Support picolibc stdio. There was already picolibc support code present in the library for the ARM LLVM toolchain. The conditionals which selected it have been changed to use __PICOLIBC__ instead of __clang_major__. 2. Add _exit stub. Code using assert or abort end up calling _exit through the picolibc signal handling code. 3. Switch to picolibc.specs. This is needed for toolchains which don't use picolibc by default, and can also be used without trouble in toolchains where picolibc is the default. 4. Define CONFIG_PICOLIBC when using picolibc. This is enabled by default, but can be disabled on the cmake command line. 5. Define picolibc_startup to initialize all .data and .bss segments using the standard tf-m arrays. 6. Add picolibc.c to many source lists when CONFIG_PICOLIBC is defined. If this file is missign, picolibc_startup will not be defined which should cause a failure at link time. Signed-off-by: Keith Packard <keithp@keithp.com>

keith-packard · 2025-12-03T17:17:18Z

The default branch of this repository is being changed to zephyr_tf-m_v2.2.2 which will replace main shortly. Please rebase your branch atop zephyr_tf-m_v2.2.2 and force-push it. I have already changed your PR's base branch to zephyr_tf-m_v2.2.2. Also, make sure to follow the new commit guidelines documented here.

Thanks. All rebased without any conflicts. I've started another Zephyr twister run "just to be sure", but I don't expect any new issues to arise.

keith-packard · 2025-12-04T04:35:32Z

Thanks. All rebased without any conflicts. I've started another Zephyr twister run "just to be sure", but I don't expect any new issues to arise.

And still passes a twister run in Zephyr. I've updated my Zephyr PR related to this (zephyrproject-rtos/zephyr#94367)

This adds linker script bits and compiler options so that trusted-firmware-m will build with picolibc. This has not been merged to the Zephyr trusted-firmware-m repository yet, that PR is: zephyrproject-rtos/trusted-firmware-m#134 Signed-off-by: Keith Packard <keithp@keithp.com>

tomi-font

Thank you, I think we can now merge this PR as it has been waiting long enough.
Be aware that my TF-M update PR is not yet merged in the Zephyr repository but it may go in any time. Just rebase your PR on top of it once it's in.

keith-packard mentioned this pull request May 19, 2025

Update Zephyr SDK to be based upon GCC 14 zephyrproject-rtos/sdk-ng#740

Closed

keith-packard force-pushed the picolibc branch 4 times, most recently from 9cd8235 to 50a91d4 Compare June 7, 2025 19:54

nashif force-pushed the main branch from c150f48 to 9e37509 Compare June 30, 2025 12:45

github-actions bot mentioned this pull request Jul 11, 2025

Changes required for SDK 0.18 for testing using SDK 0.17 zephyrproject-rtos/zephyr#93042

Closed

keith-packard force-pushed the picolibc branch from 50a91d4 to 3cbe118 Compare July 21, 2025 21:55

github-actions bot mentioned this pull request Jul 21, 2025

Switch bootloaders to picolibc zephyrproject-rtos/zephyr#93470

Closed

keith-packard force-pushed the picolibc branch 5 times, most recently from 85833fd to 01be64f Compare July 27, 2025 23:27

tomi-font reviewed Jul 28, 2025

View reviewed changes

tomi-font requested a review from wearyzen July 29, 2025 09:28

keith-packard mentioned this pull request Aug 11, 2025

Tracking issues with 1.0 and GNU/LLVM toolchain zephyrproject-rtos/sdk-ng#933

Open

28 tasks

keith-packard mentioned this pull request Aug 11, 2025

modules: Update trusted-firmware-m for picolibc zephyrproject-rtos/zephyr#94367

Closed

github-actions bot mentioned this pull request Aug 11, 2025

treewide: Merge all of the SDK 1.0 changes together zephyrproject-rtos/zephyr#94368

Closed

etienne-lms reviewed Nov 4, 2025

View reviewed changes

keith-packard force-pushed the picolibc branch from 6f5ffba to 7418104 Compare November 4, 2025 17:38

d3zd3z reviewed Nov 11, 2025

View reviewed changes

keith-packard force-pushed the picolibc branch from 7418104 to d491c61 Compare November 11, 2025 19:41

jhedberg mentioned this pull request Nov 12, 2025

West project readiness for Zephyr 4.3 zephyrproject-rtos/zephyr#97555

Open

81 tasks

tpambor approved these changes Nov 27, 2025

View reviewed changes

wearyzen approved these changes Nov 28, 2025

View reviewed changes

tomi-font changed the base branch from main to zephyr_tf-m_v2.2.2 December 3, 2025 09:03

keith-packard force-pushed the picolibc branch from d491c61 to e4bafc9 Compare December 3, 2025 17:12

keith-packard added 4 commits December 3, 2025 09:12

keith-packard force-pushed the picolibc branch from e4bafc9 to 6b820c4 Compare December 3, 2025 17:12

tomi-font approved these changes Dec 4, 2025

View reviewed changes

tomi-font merged commit fe2b910 into zephyrproject-rtos:zephyr_tf-m_v2.2.2 Dec 4, 2025

		/* Reset current position for subsequent sections */
		. = LOADADDR(.ER_CODE_SRAM) + SIZEOF(.ER_CODE_SRAM);

		@@ -0,0 +1,48 @@
		/*
		* Copyright © 2025, Keith Packard <keithp@keithp.com>

Use picolibc instead of newlib-nano #134

Use picolibc instead of newlib-nano #134

Uh oh!

Conversation

keith-packard commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

keith-packard commented Jul 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keith-packard Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomi-font left a comment

Choose a reason for hiding this comment

Uh oh!

keith-packard commented Jul 28, 2025

Uh oh!

frkv commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomi-font commented Jul 29, 2025

Uh oh!

Anton-TF commented Jul 29, 2025

Uh oh!

keith-packard commented Jul 29, 2025

Uh oh!

wearyzen commented Aug 28, 2025

Uh oh!

Vge0rge commented Nov 3, 2025

Uh oh!

JarmouniA commented Nov 3, 2025

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keith-packard commented Nov 4, 2025

Uh oh!

d3zd3z left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keith-packard commented Nov 11, 2025

Uh oh!

tpambor left a comment

Choose a reason for hiding this comment

Uh oh!

tomi-font commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

keith-packard commented Nov 28, 2025

Uh oh!

keith-packard commented Nov 28, 2025

Uh oh!

tomi-font commented Dec 1, 2025

Uh oh!

keith-packard commented Dec 1, 2025

Uh oh!

tomi-font commented Dec 3, 2025

Uh oh!

keith-packard commented Dec 3, 2025

Uh oh!

keith-packard commented Dec 4, 2025

Uh oh!

tomi-font left a comment

keith-packard commented May 19, 2025 •

edited

Loading

keith-packard Sep 9, 2025 •

edited

Loading

frkv commented Jul 29, 2025 •

edited

Loading

tomi-font commented Nov 28, 2025 •

edited

Loading