FreeBSD Support for IDF

[danny@cs.huji.ac.il]

HI,
I am using esp-idf since 1.0 very successfuly, so a big thanks!
I am using FreeBSD as my development environment, and so I have 2 request:
1- add -o ${uname -s) == "FreeBSD" in tools/kconifg/lxdialog/check-lxdialog.sh
2- this is more difficult/complicated:
I have to compile the crosstool-NG - it compiles ok, but the dowload source
version is not the same as that of the binary, so make complains with 'WARNING: Toolchain ...",
in any case the compiled runs just fine!
thanks,
danny

[ESP_Sprite]

Would you mind filing this as an issue (or better, a pull request) on the ESP-IDF github repo? That way, we can track the issue and won't forget about it.

[akilek]

Hi,

I've just made some changes on my own to get it working on FreeBSD 11.1 + p6.

I'll try to make those changes much flexible and dependent of the OS once FreeBSD is detected + simple readme to give some clues about dependencies.

Should I fork your ESP-IDF trunk code (github) and then post my changes on my fork ?

[ESP_Sprite]

Yes, the nicest way is indeed to fork esp-idf, make the changes, then file the changes as a pull request.

[Mecken76]

I'm wondering it there is support for ESP32 on FreeBSD 13.
Is it possible?

[ESP_Sprite]

Pretty sure it should be possible; ESP-IDF is written to work correctly on most POSIX-y platforms. You would need to compile your own crosscompiling toolchain; I think there are instructions for that in the ESP-IDF installation manual somewhere. Do note that we do not officially support FreeBSD, so I can't guarantee that everything works, however if you run into issues I'll be happy to see if I can help you with and if there's anything in ESP-IDF stopping FreeBSD from working, we can see if we can patch that.

[danny@cs.huji.ac.il]

after downloading the latest I decided to follow the instructions install.sh and export.sh and fantastic! it works
just had to change all my Makefiles to CMakeLists.txt and some more, but idf.py works!
so now I can continue using Freebsd 13.0.

[ESP_Sprite]

Good to hear, thanks for reporting back!

[Drohne]

Hello forum.
I also intend to use ESP-IDF to work on some ESP32 projects utilizing FreeBSD (CURRENT, 14-STABLE and 13-STABLE as of today), without Linuxulator!
With the toolchain pkg patches provided by Tomoyuki Sakurai [http://info.mkrsgh.org/blog/makerspace/ ... n-FreeBSD/ ] one is able to install a proper and recent toolchain in a standard FreeBSD ports path. After compiling the ports provided by Tomoyuki Sakurai, the FreeBSD environment provides the toolchain for IDF v5.1.1 (set via proper FLAVOR) :

/usr/local/xtensa-esp32-elf-idf51/ (basic toolchain, gcc v12.2)
/usr/local/esp-gdb-xtensa/ (ELF gdb, v12.1)

Following the instructions getting IDF v5.1.1, recen git pull is situated at

~/esp/esp-idf51/

Before altering IDF_PATH globally, running

~/esp/esp-idf51/install.sh

will pull a lot of (and most of them most likely unnecessary) Linux binaries and tries to install Python in ~/.espressif which bails out due to conflicts with standard FreeBSD packages already installed. So far, I ignored most of the errors, but it seems that some Python libraries/packages are missing, but I'll come to that later.
Pulling/installing these Linux binaries will also provide my with

~/.espressif/tools/esp-rom-elfs/

binaries, which I consider important.

After install.sh quit, IDF_PATH is set to

IDF_PATH=~/esp/esp-idf51/

and

IDF_TOOLS_PATH=~/esp/esp-idf51/tools

and running "${IDF_PATH}/tools/idf_tools.py" install-python-env.

This is now my starting point - and I fail!

Running ${IDF_PATH}/export.sh still bails out on two (mutually) important toolchain members:

[...]
Detecting the Python interpreter
Checking "python3" ...
Python 3.9.18
"python3" has been detected
Checking Python compatibility
Checking other ESP-IDF version.
ERROR: tool xtensa-esp-elf-gdb has no installed versions. Please run '/usr/local/bin/python3 ... tools/idf_tools.py install' to install it
[ along with some notes about unwanted ESP32XX types]
ERROR: tool esp32ulp-elf has no installed versions. Please run '/usr/local/bin/python3 ...
An unsupported version of tool esp32ulp-elf was found in PATH: 2.28.51 ...
[...]
ERROR: tool openocd-esp32 has no installed versions. Please run '/usr/local/bin/python3 ...
An unsupported version of tool openocd-esp32 was found in PATH: 0.11.0. To use it, run '/usr/local/bin/python3 ...
ERROR: tool esp-rom-elfs has no installed versions. Please run '/usr/local/bin/python3 ...
[...]

Running the suggested script

tools/idf_tools.py export --prefer-system

results in
[...]
ERROR: tool xtensa-esp-elf-gdb has no installed versions. Please run ...
...
WARNING: using an unsupported version of tool esp-clang found in PATH: unknown
WARNING: using an unsupported version of tool esp32ulp-elf found in PATH: 2.28.51
WARNING: using an unsupported version of tool cmake found in PATH: 3.27.7
WARNING: using an unsupported version of tool openocd-esp32 found in PATH: 0.11.0
WARNING: using an unsupported version of tool ninja found in PATH: 1.11.1
ERROR: tool esp-rom-elfs has no installed versions. Please run '/usr/local/bin/python3
export IDF_PYTHON_ENV_PATH="~/esp/esp-idf51/tools/python_env/idf5.1_py3.9_env";...
[...]

The first question is: how do I provide the proper environment variables to make the IDF scripts find

1) xtensa-esp-elf-gdb (located at /usr/local/esp-gdb-xtensa/bin/xtensa-esp32-elf-gd)
2) esp-rom-elfs (located at .espressif/tools/esp-rom-elfs/

As one can see, things do not run very well for me here. I'm sorry if my description of failure is to "longish", but I hope someone will discover my major mistake.

Since FreeBSD isn't officially supported, I aim for some workarounds setting up the environment manually as the script would do this task in a more automatica fashion, but this seems to be a mission impossible without further informations about the hierachy of variables requisite to sucessfully setup the IDF's environment.

Running idf.py at the status quo described above as suggested with "hello_world" bails out with

Please use idf.py only in an ESP-IDF shell environment.

which seems to indicate missing Python packages and/or a proper path to the IDF location where these packages might reside.

I'm not even getting close to a point from which a descent developer might catch attention to real problems.

Is it possible to completely avoid/circumvent the Python scripts and setup manually an environment?

Usually I use ANJUTA as my favorite IDE, so that might be a suitabel task to provide a working setup ...

Thanks for reading ...

[JohnnyZ]

I am using IDF 5.1 on FreeBSD 15-CURRENT.
idf.py build/flash/monitor works.

Code: Select all

tools/idf_tools.py export --prefer-system

also fails on my system but It seems that I don't need it.

I also use port that you mentioned to build GCC.
I have my IDF tools in path:

Code: Select all

PATH=$PATH:/usr/local/riscv32-esp-elf-idf51/bin:$HOME/esp32/esp-idf/tools/

When I first installed it I did these steps (you'll possibly need to install more python tools, I had some installed):

Code: Select all

pkg install -Ay python py39-click cmake py39-yaml esp_idf_monitor idf_component_manager esp-idf-kconfig py39-esptool

python3 ~/esp32/esp-idf/tools/idf_tools.py install-python-env
# edit and delete line with "cryptography>=2.1.4,<40"
$HOME/.espressif/espidf.constraints.v5.1.txt
    # it needs crypotgraphy < 40 but FreeBSD pkg installed is 41 (needed for py39-esptool)
    # just remove it from file (removing only "<40" won't work) and it will build it normally

# nice to have: to $SHELL conf add:
PATH=$PATH:/usr/local/riscv32-esp-elf-idf51/bin:$HOME/esp32/esp-idf/tools/

I did try and fail to use LLVM (from system, ports and from ESP) to build and run examples. I also tried and failed to compile ESP's LLVM on FreeBSD.
But official GCC toolchain works for examples for my ESP32-C3.

To build example:

Code: Select all

cd ./examples/get-started/blink/
rm -rf ./build
python3 ~/esp32/esp-idf/tools/idf.py set-target esp32c3
# change LED to pin that you need
python3 ~/esp32/esp-idf/tools/idf.py all

To flash it use on of:

Code: Select all

idf.py flash
esptool.py which is printed at the end of successful build