Adding support for the Adafruit QT Py ESP32-S3

[raveious]

This adds support for the Adafruit QT Py ESP32-S3 board for both the "non-psram" variant as well as the "with psram" variant. The QT Py ecosystem is designed to be compatible with Seeedstudio's Xiao ecosystem, while bringing integration with the rest of Adafruit's STEMMA QT system.

[simonguinot]

Passing this PR to the Espressif maintainers.

[nordicjm]

@raveious try rebasing on main, the original board should then work

[raveious]

@raveious try rebasing on main, the original board should then work

Rebase completed.

[sylvioalves]

Would you please remove the below? We have started removing this entries from all boards (another PR). Would be good not to keep adding this anymore.

testing:
  ignore_tags:
    - net
    - bluetooth

[raveious]

Should I also be removing the net and bluetooth from the ignore_tags section of the appcpu.yaml file?

[raveious]

is it PR #80785 ?

[raveious]

I took the lines out of the procpu.yaml files.

[sylvioalves]

@marekmatej PTAL.

[sylvioalves]

LGTM, just one last request.

[nashif]

Board revisions is the correct way to handle this, not board variants. It can use a board revision with a string for the default board in that case

@nordicjm wondering if this is correct usage of revisions, to me this looks like a board with multiple configurations rather than different revisions. IMO this is misuse of the custom revision feature.

This board comes with no psram/wih psram (https://www.adafruit.com/product/5426 vs https://www.adafruit.com/product/5700), it is not a board that was updated and has different versions.

I have seen this being done for many other boards. Why is variant not suitable to handle this case?

[raveious]

Board revisions is the correct way to handle this, not board variants. It can use a board revision with a string for the default board in that case

@nordicjm wondering if this is correct usage of revisions, to me this looks like a board with multiple configurations rather than different revisions. IMO this is misuse of the custom revision feature.

This board comes with no psram/wih psram (https://www.adafruit.com/product/5426 vs https://www.adafruit.com/product/5700), it is not a board that was updated and has different versions.

I have seen this being done for many other boards. Why is variant not suitable to handle this case?

Funny enough, the original implementation used board variants. I was asked to change it to use board revision instead.

[nordicjm]

Board revisions is the correct way to handle this, not board variants. It can use a board revision with a string for the default board in that case

@nordicjm wondering if this is correct usage of revisions, to me this looks like a board with multiple configurations rather than different revisions. IMO this is misuse of the custom revision feature.

This board comes with no psram/wih psram (https://www.adafruit.com/product/5426 vs https://www.adafruit.com/product/5700), it is not a board that was updated and has different versions.

I have seen this being done for many other boards. Why is variant not suitable to handle this case?

Variant is, as per the terminology:

In the context of board qualifiers, a variant designates a particular type or configuration of a build for a combination of SoC and CPU cluster. Common uses of the variant concept include introducing both secure and non-secure builds for platforms with Trusted Execution Environment support, or selecting the type of RAM used in a build.

So this means you have one board and you can run a number of different configurations on it, the RAM part applies to e.g. some NXP boards where you could be running from SRAM, DRAM, TCM, etc. but they all work on the same board. This board here is actually 2 different boards but the manufacturer has called them the exact same thing. You cannot use the psram one on the non-psram board because it does not have psram, therefore it is not a variant. See terminology for board revision:

An optional version string that identifies a particular revision of a hardware system. This is useful to avoid duplication of board files whenever small changes are introduced to a hardware system. See Multiple board revisions and Building for a board revision for more information.

The board files are mostly the same which is why there is only one set for the base defconfig and dts files, the only difference is one has the psram memory layout and the other does not, so there is an overlay for the psram version to enable that. Sure the intended use of board revision is for when the version of the actual hardware is updated but given that this is 2 different boards with the exact same name that are incompatible due to different SoC part numbers I don't see a way of having 2 different boards (this was also discussed with Torsten who agreed that board revision seemed most appropriate)

An example of another board doing it like this: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/others/stm32_min_dev this is actually (at least) 2 different boards by completely different manufacturers though the only difference on them is which pin in connected to a status LED

[nashif]

You cannot use the psram one on the non-psram board because it does not have psram, therefore it is not a variant. See terminology for board revision:

If it is a different board, it should not be a revision, it should be added as a new board entry in board.yml.

Variants is used in the tree for the same board with different HW features, for example right now we have rpi_pico with a /w variant, those are 2 different boards using the same name with different features. Other example exist, i.e. XIAO BLE (Sense) with a /sense variants, not sure how that fits.

We could also expand the definition of variants to support those cases of same board with different configurations and avoid creating new boards or misuing revisions.

[nordicjm]

If it is a different board, it should not be a revision, it should be added as a new board entry in board.yml.

The problem is that it's the same board, it's just a different SoC fitted to the board, they are both "qt py esp32-s32" so you can't use a board for that (unless you suffix one with _psram which is going to be similar to this)

Variants is used in the tree for the same board with different HW features, for example right now we have rpi_pico with a /w variant, those are 2 different boards using the same name with different features. Other example exist, i.e. XIAO BLE (Sense) with a /sense variants, not sure how that fits.

Mistakes were made in hwmv2 porting because people like me with no knowledge of a lot of boards rushed to convert 600+ boards into hwmv2 format, variants should not have been used for that. Likewise when you reworked something in twister recently affecting the stm32 min dev board which I then noticed had a default revision in the hwmv2 conversion, which it should not

We could also expand the definition of variants to support those cases of same board with different configurations and avoid creating new boards or misuing revisions.

But this is a revision or a separate board and not a variant, if a vendor releases a v1.0 board then a v1.5 board which might change the CPU, that's still a revision of the board, variant is for things like smp or non-smp e.g. on qemu boards or the non-secure core on trustzone supported CPUs or selecting which active configuration is used, I don't see it as useful to make variant and revision into the same thing, there should be a clear distinction between them. A board might ship with a wrong connection to a sensor then an update might fix it, there is no way you can get the sensor on the original board working whereas a non-secure core will always work on a specific board, variant should be virtual and revision should be physical

Or actually I guess another thing to think of is the soc itself, should the soc just be esp32s or should it be esp32s<some_part_number_here>, then that way you would just have 1 board but with 2 SoCs listed and would need to select the correct SoC, that's probably the most faithful way to do it but then you would need to change every board using those SoCs

[kartben]

ping @sylvioalves