feat: Add lilygo_t_display_p4 board support

[Llgok]

Description

Adapt to the new board lilygo_t_display_p4
Refer to the lilygo_t_display_p4 README for usage instructions.

Related

N/A

Testing

Compiled successfully, flashed and tested, everything works properly. Packaged firmware file: [T-Display-P4_v1.0][edge_agent]_firmware_202605080938

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[CLAassistant]

All committers have signed the CLA.

[laride]

sha=fd45798d41c1b8f9e4d133fb0797041fa0853ebc

[laride]

Thank you for your PR! We are currently going through our internal merge process.

[Llgok]

Thank you for your PR! We are currently going through our internal merge process.

@laride
Hello, I have a question about adding the audio driver and would like to confirm a possible modification approach.

Currently, the ES8311 audio initialization on lilygo_t_display_p4 does not go through the i2s peripheral defined in board_peripherals.yaml. Instead, I initialize I2S/I2C through a third-party board-level driver on my side, and then expose audio_dac/audio_adc as custom devices in setup_device.cpp.

At the moment, when lua_module_board_manager.c retrieves audio codec parameters, it depends on periph_i2s_config_t by default. This means CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT must be enabled and an I2S peripheral must be configured. However, doing so would cause Board Manager to initialize I2S again, which conflicts with the lilygo_device_driver library.

I would like to modify lua_module_board_manager.c as follows:

1. Only reference periph_i2s_config_t when CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT is enabled.
2. When the audio_codec data interface is I2S but i2s_cfg.name == NULL, allow it to use a custom/external initialized codec path.
3. Return the default sample_rate / channels / bits_per_sample from dev_audio_codec_config_t.

This would allow ES8311 DAC to work with audio.new_output() without using board_peripherals.yaml to initialize I2S.

Would this approach be acceptable, or do you have a better suggestion?

[laride]

Hello, I have a question about adding the audio driver and would like to confirm a possible modification approach.

Currently, the ES8311 audio initialization on lilygo_t_display_p4 does not go through the i2s peripheral defined in board_peripherals.yaml. Instead, I initialize I2S/I2C through a third-party board-level driver on my side, and then expose audio_dac/audio_adc as custom devices in setup_device.cpp.

At the moment, when lua_module_board_manager.c retrieves audio codec parameters, it depends on periph_i2s_config_t by default. This means CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT must be enabled and an I2S peripheral must be configured. However, doing so would cause Board Manager to initialize I2S again, which conflicts with the lilygo_device_driver library.

I would like to modify lua_module_board_manager.c as follows:

1. Only reference `periph_i2s_config_t` when `CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT` is enabled.

2. When the `audio_codec` data interface is I2S but `i2s_cfg.name == NULL`, allow it to use a custom/external initialized codec path.

3. Return the default `sample_rate / channels / bits_per_sample` from `dev_audio_codec_config_t`.

This would allow ES8311 DAC to work with audio.new_output() without using board_peripherals.yaml to initialize I2S.

Would this approach be acceptable, or do you have a better suggestion?

@LiuCodee @TDA-2030 PTAL

I noticed that this PR introduces a new Python file to handle a development board with a different configuration variant. We may need to discuss within this PR how similar scenarios should be handled going forward.

[Llgok]

Hello, I have a question about adding the audio driver and would like to confirm a possible modification approach.
Currently, the ES8311 audio initialization on lilygo_t_display_p4 does not go through the i2s peripheral defined in board_peripherals.yaml. Instead, I initialize I2S/I2C through a third-party board-level driver on my side, and then expose audio_dac/audio_adc as custom devices in setup_device.cpp.
At the moment, when lua_module_board_manager.c retrieves audio codec parameters, it depends on periph_i2s_config_t by default. This means CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT must be enabled and an I2S peripheral must be configured. However, doing so would cause Board Manager to initialize I2S again, which conflicts with the lilygo_device_driver library.
I would like to modify lua_module_board_manager.c as follows:

1. Only reference `periph_i2s_config_t` when `CONFIG_ESP_BOARD_PERIPH_I2S_SUPPORT` is enabled.

2. When the `audio_codec` data interface is I2S but `i2s_cfg.name == NULL`, allow it to use a custom/external initialized codec path.

3. Return the default `sample_rate / channels / bits_per_sample` from `dev_audio_codec_config_t`.

This would allow ES8311 DAC to work with audio.new_output() without using board_peripherals.yaml to initialize I2S.
Would this approach be acceptable, or do you have a better suggestion?

@LiuCodee @TDA-2030 PTAL

I noticed that this PR introduces a new Python file to handle a development board with a different configuration variant. We may need to discuss within this PR how similar scenarios should be handled going forward.

@laride
lilygo_t_display_p4/gen_bmgr_config_codes.py is a dedicated wrapper script for the lilygo_t_display_p4 board: it calls the official esp_board_manager/gen_bmgr_config_codes.py to generate board-level code, and then additionally appends lilygo_t_display_p4's own Kconfig.projbuild menu. The gen_bmgr_config_codes script under esp_board_manager is responsible for general YAML parsing and code generation, while my dedicated script only sets default parameters for lilygo_t_display_p4 and supplements the board-specific Kconfig.

[laride]

Thanks for the clarification. We would prefer to have a more generic solution for this kind of scenario, so that similar cases from other vendors can follow a unified approach and documentation in the future.

In addition, if we customize this Python script for a specific board, it becomes difficult for us to add build coverage for the board in CI. This would also prevent these boards from being integrated into the online flashing workflow.

The Board Manager engineers are currently discussing a suitable long-term solution for handling this type of board-specific customization. Because of that, this PR may need some more time before it can be merged.

[Llgok]

@laride
Thank you for your detailed explanation.

I will patiently wait for the results of your discussion regarding the long-term generic solution. Once you have finalized the unified approach and clarified the required adjustments, please feel free to let me know, and I will modify or update the implementation accordingly based on the new requirements.