When QEMU and the custom toolchain are not yet available in sdk-ng, is a new SoC eligible for a PR?

[youspectrum]

1. In the case where upstream QEMU does not yet support a new SoC, and the official Zephyr repository also does not include any QEMU patches or forks for that SoC, is it still permissible to submit a pull request (PR) to Zephyr adding support for this SoC and its corresponding development board?

2. Does Zephyr's CI build pipeline always build its required SDK (including toolchains, QEMU, etc.) from source? If a contributor provides a pre-built binary SDK package and temporarily points to it via an environment variable (e.g., ZEPHYR_SDK_INSTALL_DIR, QEMU_BIN_PATH), is this approach allowed or effective during the PR review and CI process?

3. If the new SoC requires a standalone GCC toolchain, a customized version of QEMU, or other non-standard SDK components, are there any prerequisite dependencies when submitting kernel and board support package (BSP) code to Zephyr? For example, must the official SDK (sdk-ng) fully support the architecture first, or is it acceptable to merge SoC/board support into the main Zephyr tree first and add full SDK support later?

[qvinhdao]

I’m also interested in this topic and would appreciate clarification on the expectations around new SoC/board support when upstream QEMU or the official Zephyr SDK does not yet support the architecture.

[MinhHDSVN]

We are porting a new architecture, but it is not supported by any simulation even QEMU. I have same the above questions. How about if we build and run test cases in local CI, then provide that logs or evidences?

[maass-hamburg]

Yes it is allowed, can be seen at #107516 and zephyrproject-rtos/docker-image#301

sdk-ng support is not mandatory. But we need something to have it build and run in the ci.