From edward.nevill at gmail.com Wed Mar 7 09:05:00 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 07 Mar 2018 09:05:00 +0000 Subject: RFR: 8199152: Configure broken for arm 32 Message-ID: <1520413500.2363.3.camel@gmail.com> Hi, Please review the following change which fixes broken configuration for arm 32. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8199152 Webrev: http://cr.openjdk.java.net/~enevill/8199152/webrev.00/ The arm 32 configure is broken after the following changes https://bugs.openjdk.java.net/browse/JDK-8198724 http://hg.openjdk.java.net/jdk/jdk/rev/c04d813140dc https://bugs.openjdk.java.net/browse/JDK-8199052 http://hg.openjdk.java.net/jdk/jdk/rev/5d35b6050163 OK to push to jdk/jdk? Thanks, Ed. From magnus.ihse.bursie at oracle.com Wed Mar 7 12:43:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Mar 2018 13:43:15 +0100 Subject: RFR: 8199152: Configure broken for arm 32 In-Reply-To: <1520413500.2363.3.camel@gmail.com> References: <1520413500.2363.3.camel@gmail.com> Message-ID: <6a9dc29c-d505-0ec5-c1d9-57586e6596b1@oracle.com> On 2018-03-07 10:05, Edward Nevill wrote: > Hi, > > Please review the following change which fixes broken configuration for > arm 32. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8199152 > Webrev: http://cr.openjdk.java.net/~enevill/8199152/webrev.00/ > > The arm 32 configure is broken after the following changes > > https://bugs.openjdk.java.net/browse/JDK-8198724 > http://hg.openjdk.java.net/jdk/jdk/rev/c04d813140dc > > https://bugs.openjdk.java.net/browse/JDK-8199052 > http://hg.openjdk.java.net/jdk/jdk/rev/5d35b6050163 > > OK to push to jdk/jdk? Fix looks good. Ok to push to jdk/jdk. I apologize for causing this mess. :( /Magnus > > Thanks, > Ed. > From edward.nevill at gmail.com Thu Mar 15 21:40:37 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Mar 2018 21:40:37 +0000 Subject: RFR: aarch32: ARM 32 build broken after 8165929 Message-ID: <1521150037.2955.5.camel@gmail.com> Hi, Please review the following webrev Bugid: https://bugs.openjdk.java.net/browse/JDK-8199243 Webrev: http://cr.openjdk.java.net/~enevill/8199243/webrev.00 The ARM 32 build is broken with multiple errors of the form /work/ed/arm32/jdk/src/hotspot/os_cpu/linux_arm/copy_linux_arm.inline.hpp:33:54: error: invalid conversion from 'const HeapWord*' to 'HeapWord*' [-fpermissive] _Copy_conjoint_words(to, from, count * HeapWordSize); The problem was introduced by change 8165929 # HG changeset patch # User coleenp # Date 1518182622 18000 # Fri Feb 09 08:23:42 2018 -0500 # Node ID 950c35ea6237afd834d02345a2878e5dc30750e0 # Parent f323537c9b75444578c75d348fa2e5be81532d3e 8165929: Constify arguments of Copy methods Reviewed-by: hseigel, kbarrett This change added 'const' to the 'from' arguments in various Copy functions, for example - void _Copy_conjoint_words(HeapWord* from, HeapWord* to, size_t count); - void _Copy_disjoint_words(HeapWord* from, HeapWord* to, size_t count); + void _Copy_conjoint_words(const HeapWord* from, HeapWord* to, size_t count); + void _Copy_disjoint_words(const HeapWord* from, HeapWord* to, size_t count); The problem in the ARM 32 port occurs in code like the following static void pd_conjoint_words(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AARCH64 _Copy_conjoint_words(from, to, count * HeapWordSize); #else // NOTE: _Copy_* functions on 32-bit ARM expect "to" and "from" arguments in reversed order _Copy_conjoint_words(to, from, count * HeapWordSize); #endif } The assembler implementation of the Copy functions in ARM 32 actually copies in the wrong order. Ie it copies from 'to' and to 'from'. Looking at the assembler implementation it says the following # Support for void Copy::conjoint_words(void* from, # void* to, # size_t count) _Copy_conjoint_words: stmdb sp!, {r3 - r9, ip} IE. It implies that it copies from 'from' and to 'to' in the comment, or in other words copies from memory pointed to by 'R0' to memory pointed to by 'R1' but in fact the implementation does the copy the other way around! The quick and dirty fix would be to apply a (const *) cast to the 'to' arguments for ARM 32. However, I think this is just too broken and misleading. My proposal is to fix this properly and have the assembler copy the correct way, and then delete the nasty conditionalisation on the calls. I also propose using symbolic names 'from' and 'to' rather than 'r0' and 'r1'. Many thanks, Ed. From david.holmes at oracle.com Fri Mar 16 02:28:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Mar 2018 12:28:01 +1000 Subject: RFR: aarch32: ARM 32 build broken after 8165929 In-Reply-To: <1521150037.2955.5.camel@gmail.com> References: <1521150037.2955.5.camel@gmail.com> Message-ID: <4a209409-165c-8e87-55ee-a896f2b341b1@oracle.com> Hi Ed, Small nit: can you please include the current bug number in the RFR email subject. Thanks. On 16/03/2018 7:40 AM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > Bugid: https://bugs.openjdk.java.net/browse/JDK-8199243 > Webrev: http://cr.openjdk.java.net/~enevill/8199243/webrev.00 > > The ARM 32 build is broken with multiple errors of the form > > /work/ed/arm32/jdk/src/hotspot/os_cpu/linux_arm/copy_linux_arm.inline.hpp:33:54: error: invalid conversion from 'const HeapWord*' to 'HeapWord*' [-fpermissive] > _Copy_conjoint_words(to, from, count * HeapWordSize); > > The problem was introduced by change 8165929 > > # HG changeset patch > # User coleenp > # Date 1518182622 18000 > # Fri Feb 09 08:23:42 2018 -0500 > # Node ID 950c35ea6237afd834d02345a2878e5dc30750e0 > # Parent f323537c9b75444578c75d348fa2e5be81532d3e > 8165929: Constify arguments of Copy methods > Reviewed-by: hseigel, kbarrett > > This change added 'const' to the 'from' arguments in various Copy functions, for example > > - void _Copy_conjoint_words(HeapWord* from, HeapWord* to, size_t count); > - void _Copy_disjoint_words(HeapWord* from, HeapWord* to, size_t count); > + void _Copy_conjoint_words(const HeapWord* from, HeapWord* to, size_t count); > + void _Copy_disjoint_words(const HeapWord* from, HeapWord* to, size_t count); > > The problem in the ARM 32 port occurs in code like the following > > static void pd_conjoint_words(const HeapWord* from, HeapWord* to, size_t count) { > #ifdef AARCH64 > _Copy_conjoint_words(from, to, count * HeapWordSize); > #else > // NOTE: _Copy_* functions on 32-bit ARM expect "to" and "from" arguments in reversed order > _Copy_conjoint_words(to, from, count * HeapWordSize); > #endif > } > > The assembler implementation of the Copy functions in ARM 32 actually copies in the wrong order. Ie it copies from 'to' and to 'from'. > > Looking at the assembler implementation it says the following > > # Support for void Copy::conjoint_words(void* from, > # void* to, > # size_t count) > _Copy_conjoint_words: > stmdb sp!, {r3 - r9, ip} > > IE. It implies that it copies from 'from' and to 'to' in the comment, or in other words copies from memory pointed to by 'R0' to memory pointed to by 'R1' but in fact the implementation does the copy the other way around! > > The quick and dirty fix would be to apply a (const *) cast to the 'to' arguments for ARM 32. However, I think this is just too broken and misleading. > > My proposal is to fix this properly and have the assembler copy the correct way, and then delete the nasty conditionalisation on the calls. I also propose using symbolic names 'from' and 'to' rather than 'r0' and 'r1'. Okay the conversion of r1 -> from, and r0 -> to, seems accurate. I'm assuming the only actual bug was in the comment. Thanks, David > Many thanks, > Ed. > From Chris.Grey at automatedlogic.com Fri Mar 16 18:57:38 2018 From: Chris.Grey at automatedlogic.com (Grey, Chris UTC CCS) Date: Fri, 16 Mar 2018 18:57:38 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: References: Message-ID: <1521226657876.52344@automatedlogic.com> I found an archived thread back a few months were someone was asking for JDK 8/9 ARMv7 binaries. However that person didn't respond with an OS and thus never got an answer as to where to find the binaries. I have the same question and here are the pertinent details of what I'm working with: TI Sitara AM3352 (ARM Cortex A8) 32-bit with hardware float which is the same family as the Beaglebone processor. In GNU terms, we use the arm-linux-gnueabihf toolkit. We are wanting to use the Open JDK Java 9 to take advantage of the jigsaw feature in order to exclude the pieces of the JVM we don't need. However if the Open JDK 8 binaries for ARM are also available, we'd like to get them too. Regards, Chris Grey ALC/Firmware From akashche at redhat.com Fri Mar 16 20:00:35 2018 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 16 Mar 2018 20:00:35 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521226657876.52344@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> Message-ID: <1727c75b-fe39-324a-78d6-6e32eabe4eb4@redhat.com> Hi Chris, On 03/16/2018 06:57 PM, Grey, Chris UTC CCS wrote: > I found an archived thread back a few months were someone was asking for JDK 8/9 ARMv7 binaries. However that person didn't respond with an OS and thus never got an answer as to where to find the binaries. > > I have the same question and here are the pertinent details of what I'm working with: > TI Sitara AM3352 (ARM Cortex A8) 32-bit with hardware float which is the same family as the Beaglebone processor. > In GNU terms, we use the arm-linux-gnueabihf toolkit. > > We are wanting to use the Open JDK Java 9 to take advantage of the jigsaw feature in order to exclude the pieces of the JVM we don't need. However if the Open JDK 8 binaries for ARM are also available, we'd like to get them too. If using a JDK pre-packaged for Linux distro is an option for you - both java-9-openjdk and java-1.8.0-openjdk-aarch32 (note, that is a separate ARM-only package, also 8u161 update in it is not yet propagated to public repos - going to be there in some days) are available in Fedora armv7hl. > > Regards, > Chris Grey > ALC/Firmware > -- -Alex From edward.nevill at gmail.com Fri Mar 16 22:17:00 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 16 Mar 2018 22:17:00 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521226657876.52344@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> Message-ID: <1521238620.2994.4.camel@gmail.com> Hi Chris, There are no binaries generally available. As Alex mentioned there should be binaries in your distro (Debian/Fedora ...). Otherwise it is a case of builing your own. To get you started I have put a jdk9u image at http://camswl.com/images/jdk9u-server-release.tar.xz All the best, Ed. On Fri, 2018-03-16 at 18:57 +0000, Grey, Chris UTC CCS wrote: > I found an archived thread back a few months were someone was asking > for JDK 8/9 ARMv7 binaries. However that person didn't respond with > an OS and thus never got an answer as to where to find the binaries. > > From akozlov at azul.com Mon Mar 19 10:37:22 2018 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 19 Mar 2018 13:37:22 +0300 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521226657876.52344@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> Message-ID: Hi, Chris, On 16.03.2018 21:57, Grey, Chris UTC CCS wrote: > We are wanting to use the Open JDK Java 9 ... However if the Open JDK 8 binaries for ARM are also available, we'd like to get them too. You can get Azul's latest OpenJDK 8 build from https://www.azul.com/downloads/zulu-embedded "ARM v8/v7/v6 Hard Float ABI" variant should match your needs. OpenJDK 9 binaries will show up there in the future, stay tuned :-) Thanks, Anton From Chris.Grey at automatedlogic.com Mon Mar 19 11:39:09 2018 From: Chris.Grey at automatedlogic.com (Grey, Chris UTC CCS) Date: Mon, 19 Mar 2018 11:39:09 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: References: <1521226657876.52344@automatedlogic.com>, Message-ID: <1521459548630.42598@automatedlogic.com> Thank you for each of your responses. The Linux distro we are using is a Yocto-based custom tarball using only the recipes that we needed in an effort to keep the entire tarball of the file system as small as possible. The bitbake application does all the cross-compiling for us. Now that we are expanding our embedded world to include Java, we now need a JVM, but would prefer to use Java 9, again to keep the filesystem footprint of the JVM as small as possible. One of your responses mentioned the JVM possibly being included, in compiled form, in other Linux distros. Is there any chance there's a bitbake recipe that we can include to simply get bitbake to compile it directly into our distro? If so, where would I find info on that. If not, are there any details pertinent to building the JVM from source that I should be aware of? If this were a traditional Linux-targetted source, I'd expect to run a configure script, which would generate a makefile that, then would complete the build. However this wouldn't be a traditional build. It's a cross-compile build where the make would need to know NOT to use the PC's native Linux GNU compiler and instead use the GNU ARM cross compiler. Thus I expect some manual configuration would be required along with likely numerous details about the target. Is there a website or a document that details exactly how this is done? Or am I simply imagining it being worse than it really is? The other option is I do have a Beaglebone Black that I could attempt to natively compile the code on. I expect that would be quite slow, but if that route would actually be the simplest option, I'm open to trying that as well. Thoughts? Chris Grey ALC/Firmware ________________________________________ From: aarch32-port-dev on behalf of Anton Kozlov Sent: Monday, March 19, 2018 6:37 AM To: Grey, Chris UTC CCS; aarch32-port-dev at openjdk.java.net Subject: [External] Re: OpenJDK ARMv7 binaries for Linux Hi, Chris, On 16.03.2018 21:57, Grey, Chris UTC CCS wrote: > We are wanting to use the Open JDK Java 9 ... However if the Open JDK 8 binaries for ARM are also available, we'd like to get them too. You can get Azul's latest OpenJDK 8 build from https://urldefense.proofpoint.com/v2/url?u=https-3A__www.azul.com_downloads_zulu-2Dembedded&d=DwICaQ&c=ilBQI1lupc9Y65XwNblLtw&r=pnpLNf5xnZMm_WTY63muGbH8kjDjFt2v-o_OZJmTHRM&m=rVH-XpAklTVECaLWCBG2QsxhSnKG-MerSziiBVRwd-M&s=YiRSImZVLLFiFrEMeVAtglud7e8djtyIXBInMtNSBFE&e= "ARM v8/v7/v6 Hard Float ABI" variant should match your needs. OpenJDK 9 binaries will show up there in the future, stay tuned :-) Thanks, Anton From akozlov at azul.com Mon Mar 19 13:00:48 2018 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 19 Mar 2018 16:00:48 +0300 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521459548630.42598@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> <1521459548630.42598@automatedlogic.com> Message-ID: On 19.03.2018 14:39, Grey, Chris UTC CCS wrote: > The Linux distro we are using is a Yocto-based custom tarball using only the recipes that we needed in an effort to keep the entire tarball of the file system as small as possible. The bitbake application does all the cross-compiling for us. Now that we are expanding our embedded world to include Java, we now need a JVM, but would prefer to use Java 9, again to keep the filesystem footprint of the JVM as small as possible. As far as I know, there are yocto layers for Azul's Zulu https://github.com/zulu-openjdk/meta-zulu-java https://github.com/zulu-openjdk/meta-azul-zulu-java These layers download binary from the website instead of building. You can use this as a starting point for any prebuilt openjdk. > If not, are there any details pertinent to building the JVM from source that I should be aware of? If this were a traditional Linux-targetted source, I'd expect to run a configure script, which would generate a makefile that, then would complete the build. However this wouldn't be a traditional build. It's a cross-compile build where the make would need to know NOT to use the PC's native Linux GNU compiler and instead use the GNU ARM cross compiler. Thus I expect some manual configuration would be required along with likely numerous details about the target. Is there a website or a document that details exactly how this is done? Or am I simply imagining it being worse than it really is? Cross-compilation of OpenJDK is relatively easy, thanks for underlying autoconf. Most of cross-compilation tutorials for linux will make sense. Yes, you need to provide additional info for configure, but it's not rocket science. Please refer to scripts in aarch32-port root repository for examples targeted Raspberry PI: cross_configure.sh and cross_make.sh calls configure and make with most of parameters specified, except sysroot on your build system, of course. You can adjust scripts for your needs. Thanks, Anton From Chris.Grey at automatedlogic.com Mon Mar 19 13:01:59 2018 From: Chris.Grey at automatedlogic.com (Grey, Chris UTC CCS) Date: Mon, 19 Mar 2018 13:01:59 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521238620.2994.4.camel@gmail.com> References: <1521226657876.52344@automatedlogic.com>,<1521238620.2994.4.camel@gmail.com> Message-ID: <1521464518667.96890@automatedlogic.com> Edward, I'm just now getting to looking at this tarball you attached more closely. I see it's a Java9 compiled image...exactly what I was looking for to get started. I'm sure I'm not the only one looking for something like this, if anything just to get started with Java9 in an ARM realm. Can you confirm this is compiled for a hardware float? Thanks, Chris Grey ALC/Firmware ________________________________________ From: Edward Nevill Sent: Friday, March 16, 2018 6:17 PM To: Grey, Chris UTC CCS; aarch32-port-dev at openjdk.java.net Subject: [External] Re: OpenJDK ARMv7 binaries for Linux Hi Chris, There are no binaries generally available. As Alex mentioned there should be binaries in your distro (Debian/Fedora ...). Otherwise it is a case of builing your own. To get you started I have put a jdk9u image at https://urldefense.proofpoint.com/v2/url?u=http-3A__camswl.com_images_jdk9u-2Dserver-2Drelease.tar.xz&d=DwICaQ&c=ilBQI1lupc9Y65XwNblLtw&r=0a-PaGZV7YGRcmbDPNB-LB6D1TCvhh8ON9JqsOc3Jbo&m=8dJvaqKoQyNBaq6FfVjHv47WvzIgarUiW2xdeDpuEmw&s=m4W5FsOLEJokqLCLxRBlZpEGx51pkuQ5Jg2sPFeEgrk&e= All the best, Ed. On Fri, 2018-03-16 at 18:57 +0000, Grey, Chris UTC CCS wrote: > I found an archived thread back a few months were someone was asking > for JDK 8/9 ARMv7 binaries. However that person didn't respond with > an OS and thus never got an answer as to where to find the binaries. > > From edward.nevill at gmail.com Mon Mar 19 14:30:56 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 19 Mar 2018 14:30:56 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521464518667.96890@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> ,<1521238620.2994.4.camel@gmail.com> <1521464518667.96890@automatedlogic.com> Message-ID: <1521469856.2813.4.camel@gmail.com> Hi Chris, It was configured with the option --with-abi-profile=arm-vfp-hflt The different abi options are arm-vfp-sflt,arm-vfp-hflt,arm-sflt,armv5-vfp-sflt,armv6-vfp-hflt,arm64,aarch64 So I believe it should be compiled for HW float. All the best, Ed. On Mon, 2018-03-19 at 13:01 +0000, Grey, Chris UTC CCS wrote: > Edward, > I'm just now getting to looking at this tarball you attached more > closely. I see it's a Java9 compiled image...exactly what I was > looking for to get started. I'm sure I'm not the only one looking for > something like this, if anything just to get started with Java9 in an > ARM realm. > > Can you confirm this is compiled for a hardware float? > > Thanks, > Chris Grey > ALC/Firmware > > ________________________________________ > From: Edward Nevill > Sent: Friday, March 16, 2018 6:17 PM > To: Grey, Chris UTC CCS; aarch32-port-dev at openjdk.java > .net > Subject: [External] Re: OpenJDK ARMv7 binaries for Linux > > Hi Chris, > > There are no binaries generally available. As Alex mentioned there > should be binaries in your distro (Debian/Fedora ...). Otherwise it > is > a case of builing your own. > > To get you started I have put a jdk9u image at > > https://urldefense.proofpoint.com/v2/url?u=http-3A__camswl.com_images > _jdk9u-2Dserver- > 2Drelease.tar.xz&d=DwICaQ&c=ilBQI1lupc9Y65XwNblLtw&r=0a- > PaGZV7YGRcmbDPNB- > LB6D1TCvhh8ON9JqsOc3Jbo&m=8dJvaqKoQyNBaq6FfVjHv47WvzIgarUiW2xdeDpuEmw > &s=m4W5FsOLEJokqLCLxRBlZpEGx51pkuQ5Jg2sPFeEgrk&e= > > All the best, > Ed. > > On Fri, 2018-03-16 at 18:57 +0000, Grey, Chris UTC CCS > wrote: > > I found an archived thread back a few months were someone was > > asking > > for JDK 8/9 ARMv7 binaries. However that person didn't respond with > > an OS and thus never got an answer as to where to find the > > binaries. > > > > From edward.nevill at gmail.com Mon Mar 19 14:43:32 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 19 Mar 2018 14:43:32 +0000 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521459548630.42598@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> , <1521459548630.42598@automatedlogic.com> Message-ID: <1521470612.2813.14.camel@gmail.com> Hi Chris, OpenJDK is reasonably good at cross compiling. You need to specify --openjdk-target= where is something like arm-unknown-linux-gnu and also --with-sysroot= where is the location of the arm system root (presumeably you would get this from the rest of the yocto build) You will also need to specify the location of the various tools. EG CC=... LD=... AR=... etc, etc I wrote some notes about building OpenJDK including cross compilation a long time ago at http://openjdk.linaro.org/build.htm and there are some cross compilation scripts at http://hg.openjdk.java.net/aarch64-port/jdk8/file/9a781f9c1338/cross_configure and http://hg.openjdk.java.net/aarch64-port/jdk8/file/9a781f9c1338/cross_compile All the best, Ed. On Mon, 2018-03-19 at 11:39 +0000, Grey, Chris UTC CCS wrote: > Thank you for each of your responses. > > The Linux distro we are using is a Yocto-based custom tarball using > only the recipes that we needed in an effort to keep the entire > tarball of the file system as small as possible. The bitbake > application does all the cross-compiling for us. Now that we are > expanding our embedded world to include Java, we now need a JVM, but > would prefer to use Java 9, again to keep the filesystem footprint of > the JVM as small as possible. > > One of your responses mentioned the JVM possibly being included, in > compiled form, in other Linux distros. Is there any chance there's a > bitbake recipe that we can include to simply get bitbake to compile > it directly into our distro? If so, where would I find info on that. > > If not, are there any details pertinent to building the JVM from > source that I should be aware of? If this were a traditional Linux- > targetted source, I'd expect to run a configure script, which would > generate a makefile that, then would complete the build. However this > wouldn't be a traditional build. It's a cross-compile build where the > make would need to know NOT to use the PC's native Linux GNU compiler > and instead use the GNU ARM cross compiler. Thus I expect some manual > configuration would be required along with likely numerous details > about the target. Is there a website or a document that details > exactly how this is done? Or am I simply imagining it being worse > than it really is? > > The other option is I do have a Beaglebone Black that I could attempt > to natively compile the code on. I expect that would be quite slow, > but if that route would actually be the simplest option, I'm open to > trying that as well. > > Thoughts? > > > Chris Grey > ALC/Firmware > > ________________________________________ > From: aarch32-port-dev on > behalf of Anton Kozlov > Sent: Monday, March 19, 2018 6:37 AM > To: Grey, Chris UTC CCS; aarch32-port-dev at openjdk.java > .net > Subject: [External] Re: OpenJDK ARMv7 binaries for Linux > > Hi, Chris, > > On 16.03.2018 21:57, Grey, Chris UTC CCS wrote: > > We are wanting to use the Open JDK Java 9 ... However if the Open > > JDK 8 binaries for ARM are also available, we'd like to get them > > too. > > You can get Azul's latest OpenJDK 8 build from > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.azul.com_dow > nloads_zulu- > 2Dembedded&d=DwICaQ&c=ilBQI1lupc9Y65XwNblLtw&r=pnpLNf5xnZMm_WTY63muGb > H8kjDjFt2v-o_OZJmTHRM&m=rVH-XpAklTVECaLWCBG2QsxhSnKG-MerSziiBVRwd- > M&s=YiRSImZVLLFiFrEMeVAtglud7e8djtyIXBInMtNSBFE&e= > > "ARM v8/v7/v6 Hard Float ABI" variant should match your needs. > > OpenJDK 9 binaries will show up there in the future, stay tuned :-) > > Thanks, > Anton From guy.shapiro at mobi-wize.com Mon Mar 19 15:22:28 2018 From: guy.shapiro at mobi-wize.com (Guy Shapiro) Date: Mon, 19 Mar 2018 17:22:28 +0200 Subject: OpenJDK ARMv7 binaries for Linux In-Reply-To: <1521459548630.42598@automatedlogic.com> References: <1521226657876.52344@automatedlogic.com> <1521459548630.42598@automatedlogic.com> Message-ID: <9fa991ce-37cc-3036-c7ba-724876fa3690@mobi-wize.com> On 19/03/2018 13:39, Grey, Chris UTC CCS wrote: > Thank you for each of your responses. > > The Linux distro we are using is a Yocto-based custom tarball using only the recipes that we needed in an effort to keep the entire tarball of the file system as small as possible. The bitbake application does all the cross-compiling for us. Now that we are expanding our embedded world to include Java, we now need a JVM, but would prefer to use Java 9, again to keep the filesystem footprint of the JVM as small as possible. > > One of your responses mentioned the JVM possibly being included, in compiled form, in other Linux distros. Is there any chance there's a bitbake recipe that we can include to simply get bitbake to compile it directly into our distro? If so, where would I find info on that. You may want to check out the 'meta-java' layer. It includes bitbake recipes for openjdk. I wrote a patch to update the recipe to jdk8 form aarch32. It is available on https://patchwork.openembedded.org/patch/146560/. Guy.