!LdaNPfUfvefOLewEIM:matrix.org

esp-rs

925 Members
Using Rust on the ESP series microcontrollers. https://github.com/esp-rs | https://matrix.to/#/#esp-rs-community-meetins:matrix.org | https://esp-rs.github.io/book/overview.html94 Servers

Load older messages


SenderMessageTime
7 Jul 2022
@n3xed:matrix.orgn3xed
In reply to @bennun:matrix.org

Wondering if anyone knows a way around this:

I have a cargo workspace with two binary crates and several library crates containing shared functionality between the two. Both binaries are for the ESP32-C3 target and depend on esp-idf-sys. One of the libraries also depends on esp-idf-sys as it provides wrappers around some components.

My issue is that I need to configure ESP-IDF differently for each binary crate (they have very different requirements). Using a workspace, the esp-idf-sys dependency is shared, and it seems sdkconfig must be in the root. I need a different sdkconfig for each binary.

I don't want to lose the benefits of a workspace if I can avoid it. A bunch of config in the root's Cargo.toml and .cargo/config.toml are shared, and being able to build the whole lot in one go when I modify one of the dependency libraries is super useful...

Basically, if I could somehow force esp-idf-sys to build totally separately for each binary, that would be ideal?

Actually, sdkconfig doesn't have to bee in root. You can specify its location with environment variables (see the Configuration section of the esp-idf-sys readme). You can create to seperate sdkconfigs and invoke cargo with different environment variables, so that a different sdkconfig will get picked up.
12:11:12
@n3xed:matrix.orgn3xed you could even make it easier to compile and flash by using cargo alias'es 12:13:10
@bennun:matrix.orgtorin
In reply to @n3xed:matrix.org
Actually, sdkconfig doesn't have to bee in root. You can specify its location with environment variables (see the Configuration section of the esp-idf-sys readme). You can create to seperate sdkconfigs and invoke cargo with different environment variables, so that a different sdkconfig will get picked up.
Cool, thanks. I've considered this as an option and it works for some cases, but if I'm rebuilding both targets fairly frequently then this is obviously slow, as there's only one cached ESP-IDF build and it needs a total rebuild every time I change the selected sdkconfig
12:13:20
@bennun:matrix.orgtorinDidn't know about the aliases! Very cool.12:13:47
@n3xed:matrix.orgn3xed
In reply to @bennun:matrix.org
Cool, thanks. I've considered this as an option and it works for some cases, but if I'm rebuilding both targets fairly frequently then this is obviously slow, as there's only one cached ESP-IDF build and it needs a total rebuild every time I change the selected sdkconfig
I don't know if that works, but you could try setting different target directories for the two invocations
12:14:58
@svenstaro:matrix.orgsvenstaro
In reply to @p3zhy:matrix.org
//build.rs use std::env; fn main() -> anyhow::Result<()> { let dir = env::var("CARGO_MANIFEST_DIR").unwrap(); println!("cargo:rustc-link-lib=esp_littlefs"); println!("cargo:rustc-link-search={dir}/lib"); embuild::build::CfgArgs::output_propagated("ESP_IDF")?; embuild::build::LinkArgs::output_propagated("ESP_IDF") }
So hang on, can you post some proper code here? That one was hard to read
12:15:02
@bennun:matrix.orgtorin
In reply to @n3xed:matrix.org
I don't know if that works, but you could try setting different target directories for the two invocations
Ah, that could work, I'll look into it. Thanks!
12:19:57
@p3zhy:matrix.orgp3zhyasd.png
Download asd.png
12:20:28
@svenstaro:matrix.orgsvenstaro
In reply to @p3zhy:matrix.org
sent an image.
hm but seems good, you sure you're also importing the stuff in the code?
12:46:54
@svenstaro:matrix.orgsvenstaro

something like this near the top of your main.rs also required:

mod bindings {
    #![allow(non_upper_case_globals)]
    #![allow(non_camel_case_types)]
    #![allow(non_snake_case)]
    #![allow(dead_code)]
    #![allow(deref_nullptr)]
    #![allow(rustdoc::broken_intra_doc_links)]
    include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
}

12:47:34
@svenstaro:matrix.orgsvenstarodid you do that?12:47:37
@svenstaro:matrix.orgsvenstaroyou should probably read the bindgen docs to actually get a feeling how it's supposed to be used :)12:49:05
@p3zhy:matrix.orgp3zhy
In reply to @svenstaro:matrix.org
you should probably read the bindgen docs to actually get a feeling how it's supposed to be used :)
I already added esp_littlefs library to idf components. libesp_littlefs.a file is created. This means that the compilation is done correctly. Isn't embuild responsible for creating functions in binding.rs?
12:57:50
@svenstaro:matrix.orgsvenstaro p3zhy: but did you actually include the thing in your main.rs? 12:59:20
@ivmarkov:matrix.orgivmarkov
In reply to @p3zhy:matrix.org
I already added esp_littlefs library to idf components. libesp_littlefs.a file is created. This means that the compilation is done correctly. Isn't embuild responsible for creating functions in binding.rs?
Embuild only has some utilities for invoking bindgen in an easier way. But you still have to do it explicitly one way or the other.
12:59:22
@ivmarkov:matrix.orgivmarkovAlso bindgen is not operating onlibraries at all, but on c headers. Reading its docu will help you 13:00:26
@n3xed:matrix.orgn3xed
In reply to @p3zhy:matrix.org
I already added esp_littlefs library to idf components. libesp_littlefs.a file is created. This means that the compilation is done correctly. Isn't embuild responsible for creating functions in binding.rs?

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourselve in a buildscript (passing all relevant flags), this only worke if the component you're compiling doesn't require esp-idf API's.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).
    Hopefully, this helpy.
13:32:34
@n3xed:matrix.orgn3xed
In reply to @p3zhy:matrix.org
I already added esp_littlefs library to idf components. libesp_littlefs.a file is created. This means that the compilation is done correctly. Isn't embuild responsible for creating functions in binding.rs?
*

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourselve in a buildscript (passing all relevant flags), this only worke if the component you're compiling doesn't require esp-idf APIs.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).
    Hopefully, this helpy.
13:33:43
@n3xed:matrix.orgn3xed *

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourselve in a buildscript (passing all relevant flags), this only works if the component you're compiling doesn't require esp-idf APIs.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).
    Hopefully, this helpy.
13:35:23
@n3xed:matrix.orgn3xed *

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourself in a buildscript (passing all relevant flags), this only works if the component you're compiling doesn't require esp-idf APIs.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).
    Hopefully, this helpy.
13:36:47
@n3xed:matrix.orgn3xed *

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourself in a buildscript (passing all relevant flags), this only works (easily) if the component you're compiling doesn't require esp-idf APIs.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).
    Hopefully, this helpy.
13:38:12
@julescomte:matrix.orgdecentclock
In reply to @ivmarkov:matrix.org
Are you using esp-idf 4.3? By any chance? Switch to 4.4. realpath is not defined in 4.3 and was defined in 4.4 recently: https://github.com/espressif/esp-idf/issues/7798

I am using 4.3 yes. I don't use 4.4 because i am using a library that places a big chunk of data in DROM, and the ESP-C3 would end up complaining like this:

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

�
 I�ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000 [_iram_data_end:??:??],len:0x928
load:0x403d0000 [_iram_data_end:??:??],len:0x2ce0
entry 0x403ce000 [_iram_data_end:??:??]
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (41) boot.esp32c3: SPI Speed      : 80MHz
I (45) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c060020 size=21a84h (137860) map
I (134) esp_image: segment 1: paddr=00031aac vaddr=3fc89c00 size=015ech (  5612) load
I (135) esp_image: segment 2: paddr=000330a0 vaddr=40380000 size=09a50h ( 39504) load
I (147) esp_image: segment 3: paddr=0003caf8 vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003cb10 vaddr=00000000 size=04f90h ( 20368)
I (159) esp_image: segment 5: paddr=00041aa8 vaddr=3c081aa8 size=00150h (   336) map
I (165) esp_image: segment 6: paddr=00041c00 vaddr=00000000 size=0e418h ( 58392)
I (182) esp_image: segment 7: paddr=00050020 vaddr=42000020 size=52964h (338276) map
I (235) boot: Loaded app from partition at offset 0x10000
I (236) boot: Disabling RNG early entropy source...
E (236) boot: Image contains multiple DROM segments. Only the last one will be mapped.
13:40:32
@n3xed:matrix.orgn3xed *

The way bindgen generates bindings is, it gets passed some C include directories (library headers), additional flags (target triple, C or C++, ...), and the sysroot (directory with the system headers) and finally specific header file (bindings.h in our case) that tells bindgen which bindings to generate by including all relevant C headers. Now, since you already added the component to esp-idf/components the esp-idf-sys's buildscript (actually esp-idf's cmake build system) will automatically pick it up and build it (since it automatically builds all components). The only thing left is to generate rust C bindings, which you can do two ways:

  1. Invoke bindgen yourself in a buildscript (passing all relevant flags), this only works (easily) if the component you're compiling doesn't require esp-idf APIs.
  2. Modify bindings.h of the esp-idf-sys crate and include your library's headers (you can clone the esp-idf-sys repo locally, modify it and use it by using the [patch] section in your Cargo.tom).

Hopefully, this helps.

13:41:02
@julescomte:matrix.orgdecentclock
In reply to @ivmarkov:matrix.org
Are you using esp-idf 4.3? By any chance? Switch to 4.4. realpath is not defined in 4.3 and was defined in 4.4 recently: https://github.com/espressif/esp-idf/issues/7798
*

Thanks for your response, I am using 4.3 yes. I don't use 4.4 because i am using a library that places a big chunk of data in DROM, and the ESP-C3 would end up complaining like this:

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

�
 I�ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000 [_iram_data_end:??:??],len:0x928
load:0x403d0000 [_iram_data_end:??:??],len:0x2ce0
entry 0x403ce000 [_iram_data_end:??:??]
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (41) boot.esp32c3: SPI Speed      : 80MHz
I (45) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c060020 size=21a84h (137860) map
I (134) esp_image: segment 1: paddr=00031aac vaddr=3fc89c00 size=015ech (  5612) load
I (135) esp_image: segment 2: paddr=000330a0 vaddr=40380000 size=09a50h ( 39504) load
I (147) esp_image: segment 3: paddr=0003caf8 vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003cb10 vaddr=00000000 size=04f90h ( 20368)
I (159) esp_image: segment 5: paddr=00041aa8 vaddr=3c081aa8 size=00150h (   336) map
I (165) esp_image: segment 6: paddr=00041c00 vaddr=00000000 size=0e418h ( 58392)
I (182) esp_image: segment 7: paddr=00050020 vaddr=42000020 size=52964h (338276) map
I (235) boot: Loaded app from partition at offset 0x10000
I (236) boot: Disabling RNG early entropy source...
E (236) boot: Image contains multiple DROM segments. Only the last one will be mapped.

This problem doesn't show up in 4.3.2. So either I find a way around the linker problem above, or I find a way around this multiple DROM segments error here :)

13:42:13
@mabez:matrix.orgmabez
In reply to @julescomte:matrix.org

Thanks for your response, I am using 4.3 yes. I don't use 4.4 because i am using a library that places a big chunk of data in DROM, and the ESP-C3 would end up complaining like this:

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

�
 I�ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000 [_iram_data_end:??:??],len:0x928
load:0x403d0000 [_iram_data_end:??:??],len:0x2ce0
entry 0x403ce000 [_iram_data_end:??:??]
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (41) boot.esp32c3: SPI Speed      : 80MHz
I (45) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c060020 size=21a84h (137860) map
I (134) esp_image: segment 1: paddr=00031aac vaddr=3fc89c00 size=015ech (  5612) load
I (135) esp_image: segment 2: paddr=000330a0 vaddr=40380000 size=09a50h ( 39504) load
I (147) esp_image: segment 3: paddr=0003caf8 vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003cb10 vaddr=00000000 size=04f90h ( 20368)
I (159) esp_image: segment 5: paddr=00041aa8 vaddr=3c081aa8 size=00150h (   336) map
I (165) esp_image: segment 6: paddr=00041c00 vaddr=00000000 size=0e418h ( 58392)
I (182) esp_image: segment 7: paddr=00050020 vaddr=42000020 size=52964h (338276) map
I (235) boot: Loaded app from partition at offset 0x10000
I (236) boot: Disabling RNG early entropy source...
E (236) boot: Image contains multiple DROM segments. Only the last one will be mapped.

This problem doesn't show up in 4.3.2. So either I find a way around the linker problem above, or I find a way around this multiple DROM segments error here :)

esptool usually merges adjacent sections, 0x3c060020 + 0x21a84 == 0x3C081AA4, but the following section has the address 0x3c081aa8, a 4 byte difference so it doesn't seem to be able to merge those sections into one
13:48:00
@mabez:matrix.orgmabez
In reply to @julescomte:matrix.org

Thanks for your response, I am using 4.3 yes. I don't use 4.4 because i am using a library that places a big chunk of data in DROM, and the ESP-C3 would end up complaining like this:

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

�
 I�ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000 [_iram_data_end:??:??],len:0x928
load:0x403d0000 [_iram_data_end:??:??],len:0x2ce0
entry 0x403ce000 [_iram_data_end:??:??]
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (41) boot.esp32c3: SPI Speed      : 80MHz
I (45) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c060020 size=21a84h (137860) map
I (134) esp_image: segment 1: paddr=00031aac vaddr=3fc89c00 size=015ech (  5612) load
I (135) esp_image: segment 2: paddr=000330a0 vaddr=40380000 size=09a50h ( 39504) load
I (147) esp_image: segment 3: paddr=0003caf8 vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003cb10 vaddr=00000000 size=04f90h ( 20368)
I (159) esp_image: segment 5: paddr=00041aa8 vaddr=3c081aa8 size=00150h (   336) map
I (165) esp_image: segment 6: paddr=00041c00 vaddr=00000000 size=0e418h ( 58392)
I (182) esp_image: segment 7: paddr=00050020 vaddr=42000020 size=52964h (338276) map
I (235) boot: Loaded app from partition at offset 0x10000
I (236) boot: Disabling RNG early entropy source...
E (236) boot: Image contains multiple DROM segments. Only the last one will be mapped.

This problem doesn't show up in 4.3.2. So either I find a way around the linker problem above, or I find a way around this multiple DROM segments error here :)

* esptool usually merges adjacent sections, 0x3c060020 + 0x21a84 == 0x3C081AA4, but the following DROM section has the address 0x3c081aa8, a 4 byte difference so it doesn't seem to be able to merge those sections into one
13:48:17
@ivmarkov:matrix.orgivmarkov
In reply to @julescomte:matrix.org

Thanks for your response, I am using 4.3 yes. I don't use 4.4 because i am using a library that places a big chunk of data in DROM, and the ESP-C3 would end up complaining like this:

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

�
 I�ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000 [_iram_data_end:??:??],len:0x928
load:0x403d0000 [_iram_data_end:??:??],len:0x2ce0
entry 0x403ce000 [_iram_data_end:??:??]
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (41) boot.esp32c3: SPI Speed      : 80MHz
I (45) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c060020 size=21a84h (137860) map
I (134) esp_image: segment 1: paddr=00031aac vaddr=3fc89c00 size=015ech (  5612) load
I (135) esp_image: segment 2: paddr=000330a0 vaddr=40380000 size=09a50h ( 39504) load
I (147) esp_image: segment 3: paddr=0003caf8 vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003cb10 vaddr=00000000 size=04f90h ( 20368)
I (159) esp_image: segment 5: paddr=00041aa8 vaddr=3c081aa8 size=00150h (   336) map
I (165) esp_image: segment 6: paddr=00041c00 vaddr=00000000 size=0e418h ( 58392)
I (182) esp_image: segment 7: paddr=00050020 vaddr=42000020 size=52964h (338276) map
I (235) boot: Loaded app from partition at offset 0x10000
I (236) boot: Disabling RNG early entropy source...
E (236) boot: Image contains multiple DROM segments. Only the last one will be mapped.

This problem doesn't show up in 4.3.2. So either I find a way around the linker problem above, or I find a way around this multiple DROM segments error here :)

If you have to stay on 4.3.X (which would be rather unfortunate) you can design your own simplistic realpath, that possibly returns its input argument. If you don't plan on using filesystems with the ESP-IDF, this code anyway is not so relevant. It is just that some realpath has to be there. You can even code it in Rust and then export it to the C world with extern "C". Here's the current realpath in ESP-IDF V4.4+ which is a bit more sophisticated, but again, if you don't mount filesysems you don't need that complexity: https://github.com/espressif/esp-idf/blob/release/v4.4/components/newlib/realpath.c
15:20:22
@julescomte:matrix.orgdecentclock
In reply to @ivmarkov:matrix.org
If you have to stay on 4.3.X (which would be rather unfortunate) you can design your own simplistic realpath, that possibly returns its input argument. If you don't plan on using filesystems with the ESP-IDF, this code anyway is not so relevant. It is just that some realpath has to be there. You can even code it in Rust and then export it to the C world with extern "C". Here's the current realpath in ESP-IDF V4.4+ which is a bit more sophisticated, but again, if you don't mount filesysems you don't need that complexity: https://github.com/espressif/esp-idf/blob/release/v4.4/components/newlib/realpath.c
Ok thanks ! What do you think of this multiple DROMS problem I mentioned above ? That's what preventing me from using 4.4
15:21:41
@ivmarkov:matrix.orgivmarkov
In reply to @julescomte:matrix.org
Ok thanks ! What do you think of this multiple DROMS problem I mentioned above ? That's what preventing me from using 4.4
No idea, but I think mabez is on to it...
15:22:40
@julescomte:matrix.orgdecentclock
In reply to @ivmarkov:matrix.org
No idea, but I think mabez is on to it...
Ok thanks - I have a very small code example that reproduces it. mabez let me know if that would be helpful
15:23:46

There are no newer messages yet.


Back to Room List