Build Instructions for Raspberry Pi devices #5621
Comments
|
@kphillisjr Linux ARM support is still in development |
|
@janvorli, I know that Linux Arm support is a work-in-progress, and I personally would not mind helping with it's development, and I need documentation on how to get CoreCLR running on my arm device to be able to help with the Regression tests. I have the following boards ready to use.
|
|
Ah, ok. Just in case you are not aware of that, there is some basic information on cross building for ARM Linux here: |
|
I was reading over documents and build documentation and noticed something. The Build configuration for ARM appears to be geared towards chips with VFPv3 floating point, this means chips like the ARMv7-A (aka Cortex-A series ) or newer SoC. The ARM1176 series found in the Raspberry Pi Model 1 supports only VFPv2 floating point. As a quick note a good explanation of ARM floating point can be found on debian's wiki. |
|
@BruceForstall Does the CoreCLR JIT have any support for "A32," i.e. non-Thumb, instruction encoding generation? If not, that would probably be a bigger hurdle to the Pi-1 than lack of VFPv3 support. IIRC, ARM11 is ARMv6 and doesn't support Thumb-2, which is the usual target for the ARM JIT. |
|
The RyuJIT legacy_backend path only supports the Thumb-2 ISA. |
|
For the most part it should be fairly easy to implement a Thumb back-end if the Thumb-2 ISA is already in place. The only major change is that Thumb lacks some of the newer instructions found in Thumb-2. Also, I do know that ARM has a couple of quick reference cards that should help with identifying the instructions that are not available.
Also as a quick Note, the Raspberry PI 1 supports Thumb, and VFPv2. |
|
Hi, Just wanted to add to this thread. I've tried building from source on my Raspberry Pi 3 and receive a Seg Fault in corhlpr.h within the struct COR_ILMETHOD referencing line 610. I've followed the build instructions and have also built libunwind from source which includes the required change mentioned to prevent access to inaccessible memory. This is using the latest Raspbian build. I've also tried building in release mode but this did not succeed either, however it failed in a different location with a different error (will post actual release mode error when I'm back home!). If there's any other info I can provide then please let me know! Thanks, Ian |
|
Raised as new issue dotnet/coreclr#5561 |
|
I have been trying to get the coreclr build prerequisites installed on raspberry pi 3 following https://github.com/dotnet/coreclr/blob/master/Documentation/building/cross-building.md but i hit a issues when trying to install i get the following error uname -a |
|
@maartenmensink - you are running 32 bit linux on the Pi3 (see the armv7l, 64 bit would be armv8) . The aarch64 should be used only in the case you were running 64 bit Linux. The fact that the processor is 64 bit doesn't mean the OS needs to be 64 bit and the Raspian and other distros recommended at the raspberry site are all 32 bit ones. |
|
@janvorli sadly the 32bits gives the same result
so either the default raspbian image doesn't have the proper apt-get sources or the package isnt available for the arm architecture. |
|
@maartenmensink , If you are trying to build inside RPi3 (running in 32bit raspbian or ubuntu mate or any other linux) it wouldn't build. It is not ready yet. Please try in x86-64 host (I use Ubuntu 16.04, 64 bit) cross compilation. |
|
@maartenmensink , sorry for wrong explanation. I also had same problem with I think you may need to install these. |
|
@seanshpark After checking out the repo and running
but there is another roadblock |
|
@maartenmensink , SOS is for debugging. You can try (1) disable SOS, (2) build your own clang and lldb. BTW, which Linux are you using? |
|
@seanshpark i am using |
|
@maartenmensink , I've got CoreCLR build success in RPi3. To run any program with this, next step would be to build CoreFX. But unfortunately building native ARM CoreFX may not be possible (or this also I may be wrong?) inside RPi3. For this you may need to build from x86-64 cross compilation. |
|
I am using clang 3.7 / lldb-3.7-dev to build stuff on my RPI3 with Raspbian jessie. For corefx native components: For coreclr, I needed to patch the build files to support clang3.7 / lldb-3.7 like this: diff --git a/src/ToolBox/SOS/lldbplugin/CMakeLists.txt b/src/ToolBox/SOS/lldbplugin/CMakeLists.txt
index 1424cff..fc0acd7 100644
--- a/src/ToolBox/SOS/lldbplugin/CMakeLists.txt
+++ b/src/ToolBox/SOS/lldbplugin/CMakeLists.txt
@@ -45,8 +45,8 @@ if(NOT ENABLE_LLDBPLUGIN)
endif()
# Check for LLDB library
-find_library(LLDB NAMES LLDB lldb lldb-3.8 lldb-3.6 lldb-3.5 PATHS "${WITH_LLDB_LIBS}" PATH_SUFFIXES llvm NO_DEFAULT_PATH)
-find_library(LLDB NAMES LLDB lldb lldb-3.8 lldb-3.6 lldb-3.5 PATH_SUFFIXES llvm)
+find_library(LLDB NAMES LLDB lldb lldb-3.8 lldb-3.7 lldb-3.6 lldb-3.5 PATHS "${WITH_LLDB_LIBS}" PATH_SUFFIXES llvm NO_DEFAULT_PATH)
+find_library(LLDB NAMES LLDB lldb lldb-3.8 lldb-3.7 lldb-3.6 lldb-3.5 PATH_SUFFIXES llvm)
if(LLDB STREQUAL LLDB-NOTFOUND)
if(REQUIRE_LLDBPLUGIN)
message(FATAL_ERROR "Cannot find lldb-3.5, lldb-3.6 or lldb-3.8. Try installing lldb-3.6-dev (or the appropriate package for your platform)")
@@ -65,6 +65,8 @@ find_path(LLDB_H "lldb/API/LLDB.h")
if(LLDB_H STREQUAL LLDB_H-NOTFOUND)
find_path(LLDB_H "lldb/API/LLDB.h" PATHS "/usr/lib/llvm-3.8/include")
if(LLDB_H STREQUAL LLDB_H-NOTFOUND)
+ find_path(LLDB_H "lldb/API/LLDB.h" PATHS "/usr/lib/llvm-3.7/include")
+ if(LLDB_H STREQUAL LLDB_H-NOTFOUND)
find_path(LLDB_H "lldb/API/LLDB.h" PATHS "/usr/lib/llvm-3.6/include")
if(LLDB_H STREQUAL LLDB_H-NOTFOUND)
find_path(LLDB_H "lldb/API/LLDB.h" PATHS "/usr/lib/llvm-3.5/include")
@@ -78,6 +80,7 @@ if(LLDB_H STREQUAL LLDB_H-NOTFOUND)
endif()
endif()
endif()
+ endif()
endif()
message(STATUS "LLDB_H: ${LLDB_H}")And then build: |
|
I have been able to get the build working with on RPi3 raspbian jessie I used the following packages and the based on the instructions of @janvorli to include clang-3.7 in de CMakeList.txt I have create a fork with the changes from the instructions so anybody change use it. p.s. dont use a 8gb sd last build failed at 98% no more disk space oops fail |
|
@maartenmensink the qemu qemu-user-static binfmt-support and debootstrap are not needed. These are for the cross build on x64 Linux, I believe. |
|
How about building for aarch64. Should that work? It seems Microsoft Windows has AArch64 support which means theoretically it should work since the ABI is same. |
|
aarch64 doesn't work for Linux yet. There is some work done here cydhaselton/coreclr#1 to enable ARM64 on Android from where we could pull out some of the missing ASM helpers and possibly few other changes and take that as a starting point for enabling aarch64 Linux. I can selectively move those changes to the main branch if there is someone interested in working on the bringup. |
|
The build pipeline seems to be working properly on the RPi3. Now it's just compile errors. source based on commit dotnet/coreclr@fb3270f |
|
@maartenmensink ah, I am sorry, I've forgotten to mention that I have also removed the line |
|
I was able to do a full build of coreclr based on the above input with commit https://github.com/SpringIT/coreclr/commit/5bb296a8484c8d04bcc196fecaf932b88aa096ac I will create a clean setup script for raspian jessie based on the input and experience above so other people can have a go at it. i can recommend the option |
|
I would also like to commit both the changes (support for clang3.7 and the |
|
Yeah i am willing to help out! What are the PR guidelines i have to conform to? |
|
Just create a PR with those changes, I will review and merge it after the CI lab tests finish. If it is your first commit, it would ask you to electronically sign CLA and that's all. |
|
PR submitted and CLA signed dotnet/coreclr#8904 |
* add clang 3.7 support * Removing __FakePrologName="DelayLoad_Helper\suffix\()_FakeProlog" based on https://github.com/dotnet/coreclr/issues/4332#issuecomment-271990909
…t#8904) * add clang 3.7 support * Removing __FakePrologName="DelayLoad_Helper\suffix\()_FakeProlog" based on https://github.com/dotnet/coreclr/issues/4332#issuecomment-271990909
|
It seems the build script doesn't work well for ARM. When I run it on Arch like this: It still shows: |
|
@jschwartzenberg are you running on armv7 or armv8 device like RPi2 or 3? We don't support anything else due to the different instruction encoding and the armv6l from your message seems to indicate that it is RPi1 or RPi Zero or some other ARM board with armv6. |
|
@janvorli you're right, it's a RPi1. I guess it would be nice if the script could detect that case and point out it's not supported (for now?). |
|
@kphillisjr Can this issue be closed? We have good arm32 and arm64 support now. |
|
@BruceForstall This issue should not have been closed yet. The ARM32 support is still incomplete. It's taking me a while to post a comment because I haft to gather the information to provide a decent update. |
|
I just finished getting a quick todo list for finishing this task. In general the VFP engine is backwards compatible with older models so the changes to the JIT code should be trivial at best. The following tasks should cover most of the popular ARM chips and also ensure that certain edge cases work as well.
Note: The first generation Raspberry Pi should be fully functional once the VFPv2 (aka VFP11) changes are implemented. Most of the fixes involve ensuring that the newer Features of the VFPv3+ are not generated when trying to run on a system built for VFPv2. |
|
This is a useful list to have, although perhaps it deserves its own "feature" issue, and not be part of a "Build Instructions" issue, which one would think covers simply how to build and run the source code. The VFPv3-D16 question came up with https://github.com/dotnet/coreclr/issues/17043, also. I haven't looked, but don't think the JIT currently generates NEON instructions. Given all the recent activity improving SIMD and hardware intrinsics support for other platform, one can imagine also adding that support, and NEON instruction generation, for ARM, if it is desired. Overall, it seems likely that the implementation of any backward-looking support (that is, for processors more limited, or older, than what is currently supported) might need to come from the community. Improving CoreCLR support for newer processors seems more likely to be funded by Microsoft, or at least considered among other priorities. |
|
Support for the VFPvX-D16 Floating point variant is now available on coreclr in case you missed it. Cross compiling CoreCLR for Other VFP configurations |
|
ARM v6 support is tracked by #7764. Raspberry 2 and 3 work fine. If there is anything remaining worth spending time on that is not addressed by https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/cross-building.md#cross-compiling-coreclr-for-other-vfp-configurations, please open a new specific issue on it. |
ghost
locked as resolved and limited conversation to collaborators
I was looking over the documentation and noticed that there is no information how to run CoreCLR on the Raspberry Pi.
The text was updated successfully, but these errors were encountered: