boards: riscv: model USB variant of esp32c3_luatos_core as board revision

[jonkensta]

This PR removes needless repetition and fixes issue #67013 by modeling board esp32c3_luatos_core_usb as a revision of esp32c3_luatos_core rather than as a separate board. With this change, system builds for esp32c3_luatos_core@usb will now source the existing esp32c3_luatos_core.conf in mcuboot and will not require that file to be copied as detailed in the workaround for #67013.

Note that as a consequence of moving esp32c3_luatos_core_usb.dts to esp32c3_luatos_core_usb.overlay, the following is implicitly added to chosen when generating the devicetree for esp32c3_luatos_core_usb:

/ {
	chosen {
		zephyr,code-partition = &slot0_partition;
	};
};

Before this change, this overlay was present for esp32c3_luatos_core.dts and not for esp32c3_luatos_core_usb.dts. I believe this to be a minor oversight of the commit that added these files b9d3909 and not to be intentional.

[github-actions]

Hello @jonkensta, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[sylvioalves]

@feilongfl, Hi, as the luatos core support author, could you take a look in this PR?

[jonkensta]

@sylvioalves, thanks for considering this PR! I have a couple of questions for you when you have a moment:

• I managed to fix my compliance checks but I'm still failing the twister checks. I'm a little confused as to what it is checking and how I can fix it. I'll continue looking in the Contributing Guidelines but haven't found anything helpful yet.
• Is there a way to view the result of the Documentation Build check? My computer's RAM gets thrashed when I try to run make -Cdoc html and I want to make sure my documentation change renders okay.

[feilongfl]

@feilongfl, Hi, as the luatos core support author, could you take a look in this PR?

I'm interested in confirming this PR, but the earliest I can do so is by Saturday.

[MaureenHelm]

@feilongfl, Hi, as the luatos core support author, could you take a look in this PR?

I'm interested in confirming this PR, but the earliest I can do so is by Saturday.

@feilongfl ping

[feilongfl]

Sorry, I realized I forget to press this button.

[feilongfl]

@sylvioalves

I believe it's more suitable to use the board_check_revision macro for this revision check.

However, currently, the board_check_revision macro does not support strings like 'usb'.

I am considering adding STRING format to the board_check_revision macro to support revisions with any text.
Here is the draft pull request:
#67078

with this, we can simply do this in a single command like other revision.cmake

board_check_revision(FORMAT STRING OPTIONAL)

I'd like to hear your thoughts on this matter.

---

one more thing here:

Please add this line at the top of the file.

# SPDX-License-Identifier: Apache-2.0

[jonkensta]

Thank you! I added the license identifier, but I'll keep this open in case @sylvioalves weighs in and says we should switch to using board_check_revision() instead of the custom logic.

[jonkensta]

@feilongfl, thank you for the review and the suggested edits! I just realized that there is another luatOS board that uses the esp32s3 and also has a USB variant. Do you think it would be worthwhile to include that one in this change as well?

[feilongfl]

@feilongfl, thank you for the review and the suggested edits! I just realized that there is another luatOS board that uses the esp32s3 and also has a USB variant. Do you think it would be worthwhile to include that one in this change as well?

To be honest, I am still a little uncertain about whether to implement these two development boards through a board variant or a board revision.
According to the current usage of board revisions, I think it is typically for upgrading development boards.
However, while USB and non-USB development boards share similarities, they are two different board.
Therefore, I am unsure if using a board revision is correct.

[jonkensta]

To be honest, I am still a little uncertain about whether to implement these two development boards through a board variant or a board revision. According to the current usage of board revisions, I think it is typically for upgrading development boards. However, while USB and non-USB development boards share similarities, they are two different board. Therefore, I am unsure if using a board revision is correct.

Okay, understood. I was under the impression that the USB version was the same board with the only difference being that the CH343 chip was removed as a cost and ease-of-use optimization. I tried reading the luatOS board documentation to understand the situation better but it's still not clear to me what the functional differences are between the USB and non-USB versions.

If we end up closing this PR, how do you think we should fix sybuilds for the esp32c3_luatos_core_usb variant (#67013)? The only alternative fix I can think of is to create a PR for mcuboot where we copy /boot/zephyr/boards/esp32c3_luatos_core.conf to /boot/zephyr/boards/esp32c3_luatos_core_usb.conf. Is there another way?

[nordicjm]

Needs to be migrated to hwmv2

[sylvioalves]

@jonkensta, do you plan to update this?

[jonkensta]

@jonkensta, do you plan to update this?

I don't think @feilongfl is going to approve the PR, so I'm not going to put any more work into it. I'll go ahead and close it out.