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

Support for ARMv5 Linux - Headless EABI, SoftFP ABI #66

Open
jabrena opened this issue Sep 18, 2017 · 8 comments
Open

Support for ARMv5 Linux - Headless EABI, SoftFP ABI #66

jabrena opened this issue Sep 18, 2017 · 8 comments

Comments

@jabrena
Copy link

jabrena commented Sep 18, 2017

Hi,

I would like to make the proposal for Java 9 with support of ARMv5 - Headless EABI, SoftFP ABI.

Currently, Oracle only supports Java 8, for this version:
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html

But it is important to have the JVM for this version of ARM. Why?
Exist an important LEGO Mindstorms community and it is necessary to add support for them.

Many thanks in advance.

Juan Antonio

@jabrena
Copy link
Author

jabrena commented Sep 21, 2017

For the benchmark tests, I will execute the following benchmark project:
https://github.com/ev3dev-lang-java/jvm-benchmark

If exist a better way to test the performance of any JVM, I will add it in the process. At the moment, I have tested:

In the past, I tried with Zulu but that distro doesn't have support for ARM v5.
https://www.azul.com/downloads/zulu-embedded/

Juan Antonio

@jabrena
Copy link
Author

jabrena commented Sep 24, 2017

Yesterday, I tested the whole build process with the first image and I could build OpenJ9 for Linux 64-bit (x86_64)

Today, I continued with the process on a Docker image for ARM used to test developments for ARM Soft float, but in the third step, I had a problem:
https://www.eclipse.org/openj9/oj9_build.html

root@7d8f0e450da5:/home/compiler/openj9-openjdk-jdk9# /bin/bash  ./configure --with-freemarker-jar=/home/compiler/freemarker.jar
Running custom generated-configure.sh
configure: Configuration created at Sun Sep 24 19:09:31 UTC 2017.
configure: configure script generated at timestamp 1506279925.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /bin/gunzip
checking for pigz... no
checking for gzip... /bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /bin/mktemp
checking for mv... /bin/mv
checking for nawk... /usr/bin/nawk
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... mawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for a sed that does not truncate output... /bin/sed
checking for cygpath... no
checking for greadlink... no
checking for readlink... /bin/readlink
checking for df... /bin/df
checking for cpio... /bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking target system type... armv7l-unknown-linux-gnueabi
checking openjdk-build os-cpu... linux-arm
checking openjdk-target os-cpu... linux-arm
checking compilation type... native
checking for top-level directory... /home/compiler/openj9-openjdk-jdk9
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
configure: error: unsupported OpenJ9 cpu armv7l
configure exiting with result code 1
root@7d8f0e4

Where is the check about cpu armv7l?
How to fix the problem?

The complete build process is here:
ev3dev-lang-java/ev3dev-lang-java#405

Any help?

Next week, I will check for RaspberryPi 3.

Juan Antonio

@JamesKingdon
Copy link
Contributor

JamesKingdon commented Sep 25, 2017

Hi Juan,
The support for arm hasn't been completed in the OpenJ9 release, so the configure script is failing while trying to map one set of cpu names to another. The general issue of building on arm has had some discussion in #53
Once we get that resolved, I don't think there are any fundamental issues that would prevent the JVM from running on a V5 generation chip. I haven't looked into what's required to configure an OpenJDK build with suitable default sizes for the constrained environment, but it sounds like an interesting challenge!

(edit for typo)

@jabrena
Copy link
Author

jabrena commented Sep 25, 2017

Hi @JamesKingdom,

I like your comment about ARM support. In that case, I will wait for the evolution of issue #53. Meanwhile, I will improve the .dockerfile for cross-compiling this week.

Do you need some help for this tasks?

"The support for arm hasn't been completed in the OpenJ9 release, so the configure script is failing while trying to map map one set of cpu names to another. "

Juan Antonio

@JamesKingdon
Copy link
Contributor

JamesKingdon commented Sep 25, 2017

Do you need some help for this tasks?

All help is very welcome. As you can imagine, releasing OpenJ9 has taken (and continues to take) a huge amount of work, so we're prioritising heavily. I don't know when the guys that have done the work on the build scripts will have time to focus on Arm support, so anything we can do in the meantime will move us forward. There is also work going ahead to migrate the build system to Cmake (see #90 ), so it might make sense to wait for that to settle first.

@JakubVanek
Copy link

JakubVanek commented Dec 29, 2017

Hi,
I've tried to build OpenJ9 using emdebian armel compiler. The result [download]: java in QEMU at least shows its version in the interpreter mode, but then it segfaults. Everything else will probably crash as well.
Forks with nasty hacks can be found here (they are rebased on top of upstream branches):

Regards

Edit: the configure command:

bash ./configure \
    --openjdk-target=arm-linux-gnueabi \
    --with-abi-profile=arm-ev3 \
    --with-freemarker-jar=/shared/openj9/freemarker.jar \
    --with-build-jdk=/shared/openj9/jdk-9+181/ \
    --enable-headless-only \
    --with-freetype-lib=/usr/lib/arm-linux-gnueabi \
    --with-freetype-include=/usr/include \
    --with-version-pre="mindstorms" \
    AR="arm-linux-gnueabi-gcc-ar" \
    NM="arm-linux-gnueabi-gcc-nm" \
    BUILD_AR="gcc-ar" \
    BUILD_NM="gcc-nm"

@JamesKingdon
Copy link
Contributor

Great work @JakubVanek, well done! It's not the easiest thing to get to build.
I've heard that QEMU has trouble running JVMs. It would be interesting to run the executable (with -Xint) on the target processor, especially if there's any debug support to try and find out where the crash happens.
The JIT will likely take some extra effort to make sure we're not using instructions that aren't available in V5, but hopefully there aren't too many.

@JakubVanek
Copy link

I've tried running OpenJ9 on the EV3 (ARM926EJ-S):

robot@ev3dev:~/openj9/images/jre/bin$ ./java -Xint -verbose -version
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=B629F748 Handler2=B61A7738 InaccessibleAddress=B1F8B649
R0=B6D00A54 R1=000006A0 R2=B1F8B649 R3=00000000
R4=B6D00A54 R5=B6D00CC4 R6=00000000 R7=B6306210
R8=B6388390 R9=00000000 R10=000006A0
FP=B6D00AA8 IP=00000001 SP=B6D009C8 LR=B6310050
PC=B63163AC CPSR=20000010
Module=/home/robot/openj9/images/jre/lib/default/libj9vm29.so
Module_base_address=B6225000
Target=2_90_20171228_000000 (Linux 4.4.87-22-ev3dev-ev3)
CPU=arm (1 logical CPUs) (0x3942000 RAM)
----------- Stack Backtrace -----------
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2018/01/03 18:03:53 - please wait.
JVMDUMP032I JVM requested System dump using '/home/robot/openj9/images/jre/bin/core.20180103.180353.2605.0001.dmp' in response to an event
JVMDUMP010I System dump written to /home/robot/openj9/images/jre/bin/core.20180103.180353.2605.0001.dmp
JVMDUMP032I JVM requested Java dump using '/home/robot/openj9/images/jre/bin/javacore.20180103.180353.2605.0002.txt' in response to an event
JVMDUMP012E Error in Java dump: /home/robot/openj9/images/jre/bin/javacore.20180103.180353.2605.0002.txt
JVMDUMP032I JVM requested Snap dump using '/home/robot/openj9/images/jre/bin/Snap.20180103.180353.2605.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /home/robot/openj9/images/jre/bin/Snap.20180103.180353.2605.0003.trc
JVMDUMP013I Processed dump event "gpf", detail "".

The dump is here: crash.zip, if anybody wants to check it.

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

No branches or pull requests

4 participants