Trying/Strugging/Failing building a lvgl enabled micropython build


(I am working under Linux…)

The last few days I tried to build a lvgl-enable micropython for the esp32 platform.
For that I cloned the git repositories of micropython, lv_micropython and lv_binding_micropython
side by side into one directory:


I followed the instructions on how to build lv_micropython and failed.
Then I compared the files, which need to be modified between the older lv_micropython
and “my version” of micropython and found a lot more differences as those mentioned in
the description online.
I modified “my version of micropython” accordingly at places, where those changes look like
of being lvgl-related and recompiled the stuff again.

No the compilation process runs fine (beside some warnings about comparisons between unsigned and unsigned types). But the linker process failed with this output:

printf "build-GENERIC/esp-idf/bootloader_support/libbootloader_support.a\n build-GENERIC/esp-idf/driver/libdriver.a\n build-GENERIC/esp-idf/efuse/libefuse.a\n build-GENERIC/esp-idf/esp32/libesp32.a\n build-GENERIC/esp-idf/esp_ringbuf/libesp_ringbuf.a\n build-GENERIC/esp-idf/heap/libheap.a\n build-GENERIC/esp-idf/soc/libsoc.a\n build-GENERIC/esp-idf/cxx/libcxx.a\n build-GENERIC/esp-idf/pthread/libpthread.a\n build-GENERIC/esp-idf/freertos/libfreertos.a\n build-GENERIC/esp-idf/vfs/libvfs.a\n build-GENERIC/esp-idf/json/libjson.a\n build-GENERIC/esp-idf/log/liblog.a\n build-GENERIC/esp-idf/xtensa-debug-module/libxtensa-debug-module.a\n build-GENERIC/esp-idf/tcpip_adapter/libtcpip_adapter.a\n build-GENERIC/esp-idf/app_trace/libapp_trace.a\n build-GENERIC/esp-idf/app_update/libapp_update.a\n build-GENERIC/esp-idf/newlib/libnewlib.a\n build-GENERIC/esp-idf/nvs_flash/libnvs_flash.a\n build-GENERIC/esp-idf/smartconfig_ack/libsmartconfig_ack.a\n build-GENERIC/esp-idf/spi_flash/libspi_flash.a\n build-GENERIC/esp-idf/ulp/libulp.a\n build-GENERIC/esp-idf/lwip/liblwip.a\n build-GENERIC/esp-idf/mbedtls/libmbedtls.a\n build-GENERIC/esp-idf/mdns/libmdns.a\n build-GENERIC/esp-idf/esp_http_client/libesp_http_client.a\n build-GENERIC/esp-idf/esp_nghttp/libesp_nghttp.a\n build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a\n build-GENERIC/esp-idf/esp_tls/libesp_tls.a\n build-GENERIC/esp-idf/wpa_supplicant/libwpa_supplicant.a\n build-GENERIC/esp-idf/sdmmc/libsdmmc.a\n build-GENERIC/esp-idf/bt_nimble/libbt_nimble.a\n build-GENERIC/esp-idf/esp_common/libesp_common.a\n build-GENERIC/esp-idf/esp_event/libesp_event.a\n build-GENERIC/esp-idf/esp_wifi/libesp_wifi.a\n build-GENERIC/esp-idf/esp_eth/libesp_eth.a\n build-GENERIC/esp-idf/xtensa/libxtensa.a\n" > build-GENERIC/esp-idf/ldgen_libraries
GEN build-GENERIC/esp32.project.ld
LINK build-GENERIC/application.elf
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o):(.literal.tcp_close+0x0): undefined reference to `close'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o):(.literal.tcp_write+0x0): undefined reference to `write'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o):(.literal.tcp_read+0x0): undefined reference to `read'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o): In function `tcp_close':
transport_tcp.c:(.text.tcp_close+0x17): undefined reference to `close'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o): In function `tcp_write':
transport_tcp.c:(.text.tcp_write+0x22): undefined reference to `write'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o): In function `tcp_read':
transport_tcp.c:(.text.tcp_read+0x22): undefined reference to `read'
build-GENERIC/esp-idf/esp_tcp_transport/libesp_tcp_transport.a(transport_tcp.o): In function `tcp_connect':
transport_tcp.c:(.text.tcp_connect+0xc8): undefined reference to `close'
build-GENERIC/esp-idf/esp_tls/libesp_tls.a(esp_tls.o): In function `esp_tls_low_level_conn':
esp_tls.c:(.text.esp_tls_low_level_conn+0x26f): undefined reference to `close'
build-GENERIC/esp-idf/esp_tls/libesp_tls.a(esp_tls.o): In function `esp_tls_conn_delete':
esp_tls.c:(.text.esp_tls_conn_delete+0x26): undefined reference to `close'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o):(.literal.mbedtls_net_recv+0x4): undefined reference to `read'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o):(.literal.mbedtls_net_send+0x4): undefined reference to `write'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o):(.literal.mbedtls_net_free+0x4): undefined reference to `close'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o): In function `mbedtls_net_recv':
net_sockets.c:(.text.mbedtls_net_recv+0x12): undefined reference to `read'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o): In function `mbedtls_net_send':
net_sockets.c:(.text.mbedtls_net_send+0x12): undefined reference to `write'
build-GENERIC/esp-idf/mbedtls/libmbedtls.a(net_sockets.o): In function `mbedtls_net_free':
net_sockets.c:(.text.mbedtls_net_free+0x12): undefined reference to `close'
make: *** [Makefile:841: build-GENERIC/application.elf] Error 1
[1]    150038 exit 2     make clean all

I tried to figure out, what is missing, but found nothing.
Any help how to get a working lv_micropython for esp32 is very appreciated and an updated version
of the instruction how to build it would be very welcomed.

EDT: Kinda success: Compilation runs fine now (I had used “make” instead of the extended commandline given with the docs).
BUT: After flashing the firmware (which works fine too), I got a no REPL (/dev/ttyUSB0 exists though)…rshell couldn’t managed to connect.
I am out of ideas…
What can I try additionally?


You don’t need to do that.
If you clone lv_micropython you don’t need to clone micropython/lv_binding_micropython/LVGL.
You just need to clone lv_micropython with its submodules.
If you are not familiar with git submodules, please read about them.

lv_micropython contains LVGL and lv_binding_micropython as git submodules.
All you need to do is to clone lv_micropython with its submodules.
If you already cloned it without submodules, just run git update submodule --init --recursive.

If you closely follow the instructions - it should work.

The instructions don’t say to clone micropython, lv_micropython and lv_binding_micropython
side by side into one directory like you did.

Hi Amirgon,

I know lv_micropython. Its a little “outdated” – requests for updateing it already exists (ble support was added recently to the IDF-v4 part of the ESP32-version of micropyhton. Additionally the metadata of that git repo seem to be a little messy: git describe reports another (much older) version of micropython as those reflected by the raw code (1.9 (git describe vs. 1.13 (raw code)).
Furthermore: lv_micropython is difficult to update.

So I decided to try to build my own and while doing so trying to find a way to create a structure which can be updated by persons, which are not that familiar with the code of lvgl as of micropython.

So I did clone lv_micropython for reference purposes only - to compare its setup with my own. So there is no influence to what I am trying to accomplish.

As said: So far I get a clean build (beside some warnings as mentioned in my initial mail everything is fine) but flashing the firmware results in a unresponsive board (/dev/ttyUSB is there, but rshell cannot connect).

My main problem here is to figure out, what triggers the problem and how I can circumvent it.

As you mentioned, that following the instructions should work I assume you already build your own version of lv_micropython by combing both – what are your experiences are and how can those help me to accomplish the same?

Thank you very much for you support in advance!


one step further:

I could connect to /dev/ttyUSB0 with
screen /dev/ttyUSB0 115200
and I got a fast scrolling output, which I was able to fetch with an screenshot.
The screenshot is attached to this posting.

What does this error message mean and what do I need to change in my setup to prevent that

Thanks a lot for any help in advance! :slight_smile:

It is not outdated. It is up to date with most recent micropython release (1.13).
The requests for updating it are outdated… :wink:

In any case, if you want the most recent Micropython mainline it would be easier for you to merge it into lv_micropython than the other way around.

That’s right. It only affect the version printing after boot and I never took the time to fix that.
You are welcome to fix it and send a Pull Request.
Here is the GitHub issue:

Could you elaborate on this?
lv_micropython is a fork of Micropython. You can simply add Micropython as a git remote and merge into it.

Even if you want to build your own Micropython fork, how about first making sure that lv_micropython works for you?
It’s hard to say if the problem is with your changes, with your environment or with your hardware.

There is really not enough information here to be able to help.
You created your own Micropython fork, made it compile, but it doesn’t work for you. There could be a thousand reasons for that.
You can connect JTAG and try debug it, if you want.

I’m not sure what you mean by “build your own version of lv_micropython”.
I’m building and using lv_micropython from GitHub. I’m also the author and maintainer of lv_micropython and lv_binding_micropython.

What do you mean “combining both”? LVGL and Micropython? This is the purpose of lv_micropython.

After you change partitions in partition.csv or in general after you install “other” firmware, you must erase the flash with make erase, as explained in the README.

Hi amirgon,

I did erase the flash. I will try it again, to be really sure…a moment please…no…same effect.


I got it working … that is: I got the REPL prompt. Further tests need to done, though.

The problem was, that micropython/ports/esp32/partions.csv needs to be updated.
Without knowing the real sizes and/or how to calculate them, I copied the file
lv_micropython/ports/esp32/partions.csv over the above mentioned one and recompiled the how thing.
After flashing the resulting firmware onto the board a was able to connect via rshell and to get a REPL prompt.
Would it be possible, that instructions how to update partitions.csv are missing in the instructions, how to build an own version of a lvgl-enable micropython?



Editing partitions.csv has nothing to do with LVGL or the binding script.
When you build your own fork of Micropython you should plan how to partition your flash.
In case of lv_micropython I’ve already done that work.

Anyway, I’ve added a line to the README that mentions this.

Hi amirgon,

thank you for updateing the instructions! :slight_smile:

I will try to figure out, what happens to the metadata of lv_micropython with my local repo.
If I have found something I will report.