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

tfm: Build issues with some tests (posix, newlib) #75164

Closed
erwango opened this issue Jun 28, 2024 · 2 comments
Closed

tfm: Build issues with some tests (posix, newlib) #75164

erwango opened this issue Jun 28, 2024 · 2 comments
Assignees
Labels
area: TF-M ARM Trusted Firmware-M (TF-M) bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug

Comments

@erwango
Copy link
Member

erwango commented Jun 28, 2024

Describe the bug

Build issues could be seen when building ns targets

See https://github.com/zephyrproject-rtos/zephyr/actions/runs/9709152909/job/26797411658?pr=74627

INFO    - 1) tests/posix/common/portability.posix.common.newlib on b_u585i_iot02a/stm32u585xx/ns error (Build failure)
INFO    - 2) tests/posix/common/portability.posix.common.tls.newlib on b_u585i_iot02a/stm32u585xx/ns error (Build failure)
INFO    - 3) tests/posix/fs/portability.posix.fs.newlib on b_u585i_iot02a/stm32u585xx/ns error (Build failure)
INFO    - 4) tests/posix/fs/portability.posix.fs.tls.newlib on b_u585i_iot02a/stm32u585xx/ns error (Build failure)
INFO    - 5) tests/posix/headers/portability.posix.headers.newlib.with_posix_api on b_u585i_iot02a/stm32u585xx/ns error (Build failure)

INFO    - 1) tests/lib/c_lib/thrd/libraries.libc.c11_threads.newlib on b_u585i_iot02a/stm32u585xx/ns error (Build failure)
INFO    - 2) tests/lib/c_lib/thrd/libraries.libc.c11_threads.newlib_nano on b_u585i_iot02a/stm32u585xx/ns error (Build failure)

This is not specific to the board itself as the same errors could be seen with other ns target (nrf9160dk/nrf9160/ns for instance)

To Reproduce
west twister -p nrf9160dk/nrf9160/ns -s tests/lib/c_lib/thrd/libraries.libc.c11_threads.newlib

Expected behavior
Compilation ok.

Impact
Blocker

Logs and console output

`west twister -p nrf9160dk/nrf9160/ns -s tests/lib/c_lib/thrd/libraries.libc.c11_threads.newlib`

In file included from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/time.h:116,
from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/time.h:12,
from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/net/socket_select.h:22,
from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/sys/select.h:10,
from /local/home/frq07517/zephyr_sdk/zephyr-sdk-0.16.8/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/sys/types.h:50,
from /local/home/frq07517/zephyr_sdk/zephyr-sdk-0.16.8/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/stdio.h:61,
from /local/home/frq07517/zephyrproject/zephyr/twister-out/nrf9160dk_nrf9160_ns/tests/lib/c_lib/thrd/libraries.libc.c11_threads.newlib/tfm/api_ns/interface/include/mbedtls/platform.h:58,
from /local/home/frq07517/zephyrproject/modules/crypto/mbedtls/library/sha256.c:59:
/local/home/frq07517/zephyr_sdk/zephyr-sdk-0.16.8/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/time.h:56:1: error: unknown type name 'clock_t'
56 | clock_t clock (void);
| ^~~~~~~
/local/home/frq07517/zephyr_sdk/zephyr-sdk-0.16.8/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/time.h:30:1: note: 'clock_t' is defined in header '<time.h>'; did you forget to '#include <time.h>'?
29 | #include <sys/timespec.h>
+++ |+#include <time.h>
30 |
In file included from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/posix_types.h:15,
from /local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/time.h:61:
/local/home/frq07517/zephyr_sdk/zephyr-sdk-0.16.8/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/sys/_pthreadtypes.h:182:3: error: unknown type name 'clock_t'
182 | clock_t clock; /* specifiy clock for timeouts */
| ^~~~~~~
/local/home/frq07517/zephyrproject/zephyr/include/zephyr/posix/posix_types.h:76:9: error: unknown type name 'clockid_t'
76 | clockid_t clock;
| ^~~~~~~~~
[...]
/local/home/frq07517/zephyrproject/zephyr/include/zephyr/fs/fs.h:409:36: error: unknown type name 'off_t'; did you mean '_off_t'?
409 | int fs_seek(struct fs_file_t *zfp, off_t offset, int whence);
| ^~~~~
| _off_t
[...]
/local/home/frq07517/zephyrproject/zephyr/include/zephyr/sys/fdtable.h:48:17: error: expected specifier-qualifier-list before 'ssize_t'
48 | ssize_t (*read)(void *obj, void *buf, size_t sz);
| ^~~~~~~
[...]

Environment (please complete the following information):

  • OS: Ubuntu, Zephyr CI
  • Toolchain (e.g Zephyr SDK, ...): 0.16.8
  • Commit SHA or Version used: v3.7.0-rc1-524-g5e2fbe6d180
@erwango erwango added bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug area: TF-M ARM Trusted Firmware-M (TF-M) labels Jun 28, 2024
@erwango
Copy link
Member Author

erwango commented Jun 28, 2024

@aescolar, @ithinuel, @Vge0rge FYI

AlexFabre added a commit to AlexFabre/zephyr that referenced this issue Jun 28, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
zephyrproject-rtos#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
zephyrproject-rtos#75164

Signed-off-by: Alex Fabre <[email protected]>
@aescolar
Copy link
Member

aescolar commented Jul 1, 2024

Thanks @erwango
Same issue as #75205 . Closing on that others issue favor

@aescolar aescolar closed this as completed Jul 1, 2024
nashif pushed a commit that referenced this issue Jul 1, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
#75164

Signed-off-by: Alex Fabre <[email protected]>
coreboot-org-bot pushed a commit to coreboot/zephyr-cros that referenced this issue Jul 5, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
zephyrproject-rtos/zephyr#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
zephyrproject-rtos/zephyr#75164

(cherry picked from commit 9b9d455)

Original-Signed-off-by: Alex Fabre <[email protected]>
GitOrigin-RevId: 9b9d455
Change-Id: I255ff9585942b264d0cd87092e5bf6890c96bd75
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/5672378
Reviewed-by: Fabio Baltieri <[email protected]>
Tested-by: ChromeOS Prod (Robot) <[email protected]>
Reviewed-by: Eric Yilun Lin <[email protected]>
Commit-Queue: Fabio Baltieri <[email protected]>
CZKikin pushed a commit to nxp-upstream/zephyr that referenced this issue Jul 18, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
zephyrproject-rtos#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
zephyrproject-rtos#75164

Signed-off-by: Alex Fabre <[email protected]>
Devansh0210 pushed a commit to Devansh0210/zephyr that referenced this issue Jul 20, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
zephyrproject-rtos#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
zephyrproject-rtos#75164

Signed-off-by: Alex Fabre <[email protected]>
DashingR pushed a commit to tsisw/zephyr that referenced this issue Aug 15, 2024
Problem:

When flashing a multi-image project with STLink through sysbuild,
the flash utility is told to erase the whole flash between each
single image flash.

Resulting in a partial flash where only the last image is effectively
stored on flash...

Correction:

A `west flash` must not implicitly perform a mass erase on its own.

If a flash erase is required, the option has to be passed manually.

The problem is discussed in the following issue:
zephyrproject-rtos#69582

Due to CI tests errors, the correction is not applied on
eval board `b_u585i_iot02a`.

See following issue:
zephyrproject-rtos#75164

Signed-off-by: Alex Fabre <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: TF-M ARM Trusted Firmware-M (TF-M) bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Projects
None yet
Development

No branches or pull requests

3 participants