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

Add basic support for the ESP32 #96131

Closed
wants to merge 1 commit into from
Closed

Conversation

taktoa
Copy link
Member

@taktoa taktoa commented Aug 24, 2020

Motivation for this change

Created a basic cross-compilation toolchain for the ESP32 microcontroller.

To test, try running flash.bash after cloning https://github.com/taktoa/esp32-baremetal (assuming you have an ESP32 microcontroller connected on /dev/ttyUSB0 and your current user is in the dialout group). Then do:

$ stty -F /dev/ttyUSB0 180:4:18b2:8a20:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ cat /dev/ttyUSB0

and you should see a spam of "hello, world!".

I tested with the SparkFun ESP32 Thing, for other boards YMMV, though I don't know of any reason why it might not work.

CC: @Ericson2314 @cleverca22 @bgamari

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild 10.rebuild-linux: 1-10 labels Aug 24, 2020
Copy link
Member

@lheckemann lheckemann left a comment

Choose a reason for hiding this comment

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

I absolutely love the idea of building my ESP32 firmware with nix! I have some little implementation niggles, but thank you for this!

@@ -1,4 +1,4 @@
{ stdenv, targetPackages, fetchurl, fetchpatch, noSysDirs
{ stdenv, targetPackages, fetchurl, fetchFromGitHub, fetchpatch, noSysDirs
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure I like the idea of introducing all this very specific stuff in the generic gcc8 expression. At a glance, this looks to me like all these changes can be achieved using overrides? And in that case I think it would be better to have a separate expression file containing these overrides, and using the overridden version to define the stdenv for this platform.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry for the delay; it is indeed not trivially clear where this should go — maybe @Ericson2314 and/or @matthewbauer can provide some input, being familiar with stdenv/bootstrapping stuff?

Copy link
Member

Choose a reason for hiding this comment

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

Possibly here:

cc = if crossSystem.useiOSPrebuilt or false
then buildPackages.darwin.iosSdkPkgs.clang
else if crossSystem.useAndroidPrebuilt or false
then buildPackages."androidndkPkgs_${crossSystem.ndkVer}".clang
else if targetPlatform.isGhcjs
# Need to use `throw` so tryEval for splicing works, ugh. Using
# `null` or skipping the attribute would cause an eval failure
# `tryEval` wouldn't catch, wrecking accessing previous stages
# when there is a C compiler and everything should be fine.
then throw "no C compiler provided for this platform"
else if crossSystem.useLLVM or false
then buildPackages.llvmPackages_8.lldClang
else buildPackages.gcc;

Copy link
Member

Choose a reason for hiding this comment

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

I am also for putting this behind a different attribute and use overrides.

Copy link
Member

Choose a reason for hiding this comment

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

@lheckemann I think it's fine. See the very similar changes for VC4 and Redox for GCC 6. If we could break up the GCC derivation like we do with the LLVM family of projects, we could do better, but we haven't done that yet so I think GCC is just kinda doomed to be messier.

@@ -1,10 +1,23 @@
{ stdenv, fetchurl, buildPackages }:
{ stdenv, fetchurl, fetchFromGitHub, buildPackages }:
Copy link
Member

Choose a reason for hiding this comment

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

Likewise, I think an override would be nicer here.

Copy link
Member

@lheckemann lheckemann Sep 12, 2020

Choose a reason for hiding this comment

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

It could go in a separate file, taking "regular" newlib as an arg and overriding it, then put into place like here:

libcCrossChooser = name:
# libc is hackily often used from the previous stage. This `or`
# hack fixes the hack, *sigh*.
/**/ if name == "glibc" then targetPackages.glibcCross or glibcCross
else if name == "bionic" then targetPackages.bionic or bionic
else if name == "uclibc" then targetPackages.uclibcCross or uclibcCross
else if name == "avrlibc" then targetPackages.avrlibcCross or avrlibcCross
else if name == "newlib" && stdenv.targetPlatform.isMsp430 then targetPackages.msp430NewlibCross or msp430NewlibCross
else if name == "newlib" && stdenv.targetPlatform.isVc4 then targetPackages.vc4-newlib or vc4-newlib
else if name == "newlib" then targetPackages.newlibCross or newlibCross
else if name == "musl" then targetPackages.muslCross or muslCross
else if name == "msvcrt" then targetPackages.windows.mingw_w64 or windows.mingw_w64
else if stdenv.targetPlatform.useiOSPrebuilt then targetPackages.darwin.iosSdkPkgs.libraries or darwin.iosSdkPkgs.libraries
else if name == "libSystem" then targetPackages.darwin.xcode
else if name == "nblibc" then targetPackages.netbsdCross.libc
else if name == "wasilibc" then targetPackages.wasilibc or wasilibc
else if name == "relibc" then targetPackages.relibc or relibc
else if stdenv.targetPlatform.isGhcjs then null
else throw "Unknown libc ${name}";

@bgamari
Copy link
Contributor

bgamari commented Aug 24, 2020

Indeed, this looks great.

Also relevant: https://github.com/bgamari/esp32.nix.

@Mic92
Copy link
Member

Mic92 commented Sep 12, 2020

Good to see esp-idf working, setting up the SDK was such a pain!

@Mic92
Copy link
Member

Mic92 commented Sep 12, 2020

I also found that we have some tutorials in the wiki: https://nixos.wiki/wiki/ESP-IDF#See_also
Maybe this can be updated to use esp32.nix instead.

@ehmry ehmry added the 6.topic: exotic Exotic hardware or software platform label Nov 3, 2020
@Ericson2314
Copy link
Member

Ericson2314 commented Nov 18, 2020

Someone wanna rebase this? I would have merged it but for the conflicts, being more laxed than the others.

@taktoa
Copy link
Member Author

taktoa commented Nov 18, 2020

Sorry, I'm kind of busy right now, but if anyone has the time and interest I'd welcome help.

@Ericson2314
Copy link
Member

I think a few other people were interested, so 🤞.

@SuperSandro2000 SuperSandro2000 added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jan 18, 2021
@plietar
Copy link
Contributor

plietar commented Feb 7, 2021

I have a new rebased version of this PR, along with some minor improvements. What’s the best way to proceed? Should I open a new PR for it?

@Mic92
Copy link
Member

Mic92 commented Feb 7, 2021

I have a new rebased version of this PR, along with some minor improvements. What’s the best way to proceed? Should I open a new PR for it?

sure.

@taktoa
Copy link
Member Author

taktoa commented Feb 7, 2021

Feel free to open a new PR; I'll close this one

@plietar
Copy link
Contributor

plietar commented Feb 8, 2021

Opened #112401.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: merge conflict This PR has merge conflicts with the target branch 6.topic: exotic Exotic hardware or software platform 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild 10.rebuild-linux: 1-10
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants