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

Building on M1 Mac broken; here's a workaround #80

Open
robertlipe opened this issue Nov 24, 2020 · 0 comments
Open

Building on M1 Mac broken; here's a workaround #80

robertlipe opened this issue Nov 24, 2020 · 0 comments

Comments

@robertlipe
Copy link

robertlipe commented Nov 24, 2020

I'm not calling this a fix, but here's a way to get the project building on M1-equipped Macs. I don't understand Python details enough to comment much beyond being an observer.

Homebrew doesn't support M1. That's easy enough work with and is documented (though evolving) on brew's own site.

If you just set BL_CPU and let a build rip, it crashes when it mixes native (host) compiler flags with the cross compiler. You can see with the the -I ...Framework..., which is never ever going to work on RISCv-unknown-elf-gcc compiler. That seems to be run when trying to install some of the missing Python stuff. See https://pastebin.com/gXwxNNWT

The OS-provided Python doesn't seem to play nice. Install it from Homebrew. Remember to rehash so a which pip3 shows /usr/local/bin and not Xcode's from /usr/bin/.

The magic seems to be $ arch -x86_64 pip3 install configobj six pycryptodomex fdt toml.

This forces python parts to be installed in x86_64 mode - not arm64 and not RISC-v - which successfully installs. The top-level make then runs to completion.

I'll leave this here to help the next one to try. Hopefully that person is a Python person and can confirm how much of the above is actually necessary and enshrine it in the Makefiles or in the doc as appropriate.

Additionally, a "do nothing" build seems to be doing way too much. build_out/bl602_boot2 bl602_evb and bl602_std seems to be recompiling a few dozen files every time which means that the whole planet has to get relinked in each of the target builds. This means a successive make still burns 58 seconds. I don't know if all systems are doing this right now.

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

No branches or pull requests

1 participant