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

ESP32 gn support #2325

Merged
merged 21 commits into from
Aug 29, 2020
Merged

ESP32 gn support #2325

merged 21 commits into from
Aug 29, 2020

Conversation

kedars
Copy link
Contributor

@kedars kedars commented Aug 25, 2020

Problem

Add gn build for ESP32

Summary of Changes

fixes #1510

@andy31415
Copy link
Contributor

Shoud this be a draft while WIP or is it ready for review?

@andy31415 andy31415 requested a review from mspang August 25, 2020 15:25
"ESP32/SystemTimeSupport.cpp",
"FreeRTOS/SystemTimeSupport.cpp",
]
# public_configs += [ "${chip_root}/src/crypto:crypto_config" ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -106,8 +106,10 @@ source_set("system_config_header") {

public_deps = [ ":system_buildconfig" ]

if (chip_system_config_use_lwip) {
public_deps += [ "${chip_root}/src/lwip" ]
if (target_cpu != "esp32") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

target_cpu -> current_cpu

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move this condition inside src/lwip/BUILD.gn ? See e.g. third_party/mbedtls/BUILD.gn

if (chip_device_platform == "esp32") {
defines +=
[ "BLE_PLATFORM_CONFIG_INCLUDE=${chip_ble_platform_config_include}" ]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this block intended to be added? It looks like BLE_PLATFORM_CONFIG_INCLUDE is set twice here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, the upper 'if' condition had a typo, fixed.

import("//build/toolchain/gcc_toolchain.gni")

declare_args() {
ar_ext = ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they're defined here, probably makes sense to name them something like

esp32_ar
esp32_cc
esp32_cxx

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed


toolchain_args = {
current_os = "freertos"
current_cpu = cpu_ext
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be "xtensa" ? The cpu variable is typically used to determine the architecture.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been going back and forth on that myself. Finally I thought there is nothing 'xtensa' specific here, the toolchain is esp32-specific, the SDK is esp32-specific, so might as well call it 'esp32'. Thoughts? What typically goes into generic 'cpu' specific files?

Copy link
Contributor

@mspang mspang Aug 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


# ESP32 has its own mbedTLS
if (target_cpu != "esp32") {
public_deps += [ "${mbedtls_root}:mbedtls" ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this and set the |mbedtls_target| argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@kedars kedars marked this pull request as draft August 25, 2020 17:22
@github-actions
Copy link

Size increase report for "gn_nrf-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv


@github-actions
Copy link

Size increase report for "gn_linux-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv


@github-actions
Copy link

Size increase report for "gn_efr32-example-build"

File Section File VM
chip-efr32-lock-example.out .bss 0 1024
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-efr32-lock-example.out and ./pull_artifact/chip-efr32-lock-example.out:

sections,vmsize,filesize
.bss,1024,0
.debug_loc,0,719
.debug_info,0,335
.debug_str,0,179
.debug_abbrev,0,150
.debug_frame,0,4
.debug_line,0,-591


@github-actions
Copy link

Size increase report for "nrfconnect-example-build"

File Section File VM
chip-nrf52840-lock-example.elf bss 0 744
chip-nrf52840-lock-example.elf text 134 134
chip-nrf52840-lock-example.elf [LOAD #1 [RWX]] -6 -6
chip-nrf52840-lock-example.elf [LOAD #3 [RW]] 0 -8
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-nrf52840-lock-example.elf and ./pull_artifact/chip-nrf52840-lock-example.elf:

sections,vmsize,filesize
.debug_info,0,804
bss,744,0
.debug_abbrev,0,169
.debug_str,0,169
.strtab,0,151
text,134,134
.debug_line,0,88
.debug_frame,0,80
.symtab,0,64
.debug_aranges,0,16
.debug_ranges,0,16
[Unmapped],0,-1
[LOAD #1 [RWX]],-6,-6
[LOAD #3 [RW]],-8,0


@github-actions
Copy link

Size increase report for "esp32-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

BLOAT EXECUTION FAILED WITH CODE 1:
bloaty: integer overflow


@kedars
Copy link
Contributor Author

kedars commented Aug 27, 2020

Approving, looks good.

@kedars, can you confirm this is no longer WIP - given you pulled it out of draft?

@woody-apple Everything is done, 2 notes:

  • this replaces automake build on ESP32 with GN (no CMake compatibility for CHIP, I hope that's ok?)
  • QEMU tests with GN may take a while. As @mspang mentioned above we could do this in a follow-on patch. Do we want to merge it as is for now? Or should I figure out if we can make both 'automake' and 'gn' build variants work for ESP32. So that gives us a breather while we take on the qemu tests?

@kedars kedars changed the title WIP: ESP32 gn support ESP32 gn support Aug 27, 2020
@kedars
Copy link
Contributor Author

kedars commented Aug 27, 2020

Approving, looks good.
@kedars, can you confirm this is no longer WIP - given you pulled it out of draft?

@woody-apple Everything is done, 2 notes:

  • this replaces automake build on ESP32 with GN (no CMake compatibility for CHIP, I hope that's ok?)
  • QEMU tests with GN may take a while. As @mspang mentioned above we could do this in a follow-on patch. Do we want to merge it as is for now? Or should I figure out if we can make both 'automake' and 'gn' build variants work for ESP32. So that gives us a breather while we take on the qemu tests?

Ok, so I made both of these builds works

  • the default is the current automake. Pass the option CHIP_BUILD_WITH_GN=y to the build to build with GN
  • also added a GitHub workflow so the GN build is triggered as well (could you please help review the workflow changes)

I will flip the build to GN default in a follow-on PR (once I figure out what the documentation changes required to the example's README)

For the 'restyler' issue, I am not able to view what it is complaining about, if it is about using $1 without double-quotes in the esp_echo_app.sh, I intend it to be without double-quotes, so it nulls out

@woody-apple
Copy link
Contributor

FYI to whomever merges, there's a known issue that for edits to .workflows, we may need to force merge changes in (like this one).

@kedars kedars requested a review from bzbarsky-apple as a code owner August 29, 2020 19:07
@rwalker-apple
Copy link
Contributor

@saurabhst @hawk248 @jelderton ?

@rwalker-apple rwalker-apple merged commit 8617e2a into project-chip:master Aug 29, 2020
mspang added a commit to mspang/connectedhomeip that referenced this pull request Sep 16, 2020
This used to work prior to project-chip#2325, which added an unconditional
dependency on lwip even if we're using sockets. Make it conditional.
mspang added a commit to mspang/connectedhomeip that referenced this pull request Sep 16, 2020
This used to work prior to project-chip#2325, which added an unconditional
dependency on lwip even if we're using sockets. Make it conditional.
mspang added a commit that referenced this pull request Sep 17, 2020
* Allow building CHIP without lwip checked out

This used to work prior to #2325, which added an unconditional
dependency on lwip even if we're using sockets. Make it conditional.

* Fix typo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GN build parity: esp32 platform
6 participants