Multiarch support Rock64
#1
Couple questions on multiarch support. Been trying to get JRiver MediaCenter23 to run on the Rock64. They don't have an arm64 version so suggested adding armhf architecture. I think I got the architecture added correctly, supposedly no libraries missing. Problem is that I get a "segmentation fault" error when starting the app. I've checked old posts on their forum. In 2016 there were posts from a user wanting to get multiarch support added so they could load the app on a Pine64.
1. Is it possible to run a 32bit armhf app on Ayufan's Stretch minimal build?
2. Anyone have some ideas on what to look for regarding the segmentation fault? Evidently the pertinent line in the kern log I posted on the JRiver forum is;
mediacenter23 (1585) unhandled level 3 translation fault (11) at 0x00000000

Any info would be appreciated. Thanks
  Reply
#2
(09-11-2017, 07:29 PM)Farley56 Wrote: Couple questions on multiarch support. Been trying to get JRiver MediaCenter23 to run on the Rock64. They don't have an arm64 version so suggested adding armhf architecture. I think I got the architecture added correctly, supposedly no libraries missing. Problem is that I get a "segmentation fault" error when starting the app. I've checked old posts on their forum. In 2016 there were posts from a user wanting to get multiarch support added so they could load the app on a Pine64.
1. Is it possible to run a 32bit armhf app on Ayufan's Stretch minimal build?
2. Anyone have some ideas on what to look for regarding the segmentation fault? Evidently the pertinent line in the kern log I posted on the JRiver forum is;
mediacenter23 (1585) unhandled level 3 translation fault (11) at 0x00000000

Any info would be appreciated. Thanks

Prob not its Arm64 and not ArmHF so as soon as you get a ArmHF instruction bye.
You need to compile from source to Arm64 or they do.
  Reply
#3
Clarification;
Is it possible to run 32 bit armhf app if multiarch support (armhf architecture) has been added to the arm64 build? Supposedly Debian Stretch is capable of multiarch support. How one gets it added correctly and whether the Ayufan rock64 arm64 build will allow it is for discussion. Thanks
  Reply
#4
(09-11-2017, 08:34 PM)Farley56 Wrote: Clarification;
Is it possible to run 32 bit armhf app if multiarch support (armhf architecture) has been added to the arm64 build? Supposedly Debian Stretch is capable of multiarch support. How one gets it added correctly and whether the Ayufan rock64 arm64 build will allow it is for discussion. Thanks

As far as I know multiarch is for cross compiling and still will not let you run a binary on the wrong architecture.
Its not an emulator.
With the current image you need a Arm64 version, that is prob the simple answer.
Unless your going to run through qemu or something.
  Reply
#5
Yes. Armhf is supported by rock64 and my builds. OMV uses multi-arch: the system is in armhf, but some bits are arm64z
Homepage: https://ayufan.eu

Releases:
Rock/Pro 64/Pinebook Pro: LinuxChromium OS
So/Pine A64/Pinebook: LinuxAndroid 6.0Android 7.1

Buy me a Beer
  Reply
#6
Got it, appreciate the info. A dead issue because they probably won't be making an arm64 version as they already have amd64, armhf and i386 versions. I might be the only one who wants to try and get it running on arm64, no upside for them. I have it running on the Xenial Mate build but it's not real robust and I wanted to utilize the debian stretch build as it's more recent and 64bit. I can get access to the server anyway via web browser but getting it to run on the stretch build was a challenge so why not try. Just can't seem to give it up as a fail but I can't make it happen as it's not in my control, so time to put it to bed.
  Reply
#7
(09-12-2017, 08:11 AM)Farley56 Wrote: Got it, appreciate the info. A dead issue because they probably won't be making an arm64 version as they already have amd64, armhf and i386 versions. I might be the only one who wants to try and get it running on arm64, no upside for them. I have it running on the Xenial Mate build but it's not real robust and I wanted to utilize the debian stretch build as it's more recent and 64bit. I can get access to the server anyway via web browser but getting it to run on the stretch build was a challenge so why not try. Just can't seem to give it up as a fail but I can't make it happen as it's not in my control, so time to put it to bed.

They prob will do as Arm64 is relatively new but looking like becoming the defacto Arm architecture.
Its sort of like only doing I386 for Intel and not a great long term view.

Android and the phone market leads the majority of Arm architecture and think it was only Kitkat (2014) that introduced 64bit but since then 32bit and ArmHf is becoming less and less frequent.
I doubt very much they won't be making for Arm64 and its more likely they are just hiding that they haven't yet just recompiled on Arm64.

Maybe I am wrong and its just a matter of sudo
Code:
dpkg --add-architecture armhf
but got the feeling things don't work that easy on Arm, but could just be kernel support.
Ain't got my Rock yet so can not test, maybe someone will.
  Reply
#8
It works. The newer server ARM64 chips do not support ARM32. All customer chips do support ARM32/64 today as this is kind of requirement to run Android apps where not every application is compiled for arm64.

Most of my builds run ARM64, just some using ARMHF (OMV) where it is more appropriate given today's compatibility.
Homepage: https://ayufan.eu

Releases:
Rock/Pro 64/Pinebook Pro: LinuxChromium OS
So/Pine A64/Pinebook: LinuxAndroid 6.0Android 7.1

Buy me a Beer
  Reply
#9
Maybe there's hope! Good to know, thanks. I did add the armhf architecture and checked that it showed up as a foreign-architecture. Added the armhf repos, also dpkg'd the armhf libraries I got from debian.org. JRiver folks did confirm that I wasn't missing any libraries which was good. Couldn't get past the segmentation fault so the app would never fire up. Could it be a permission problem? If so, I'd assume I'd get a different error. I defer to others as I'm in over my head. The great thing is that when I bork the image I just re-Etcher it and start anew. I've loosely documented what I've tried and eliminate/add different things but get the same result. My head hurts from banging it against the wall...might be approaching the whole insanity thing.  Big Grin The worst thing is that I still believe at some point I had the armhf version running on the stretch build but I can't reproduce it. Tinker, sailor, soldier, spy. I'll keep playing till I die!
  Reply
#10
(09-12-2017, 09:39 AM)Farley56 Wrote: Maybe there's hope! Good to know, thanks. I did add the armhf architecture and checked that it showed up as a foreign-architecture. Added the armhf repos, also dpkg'd the armhf libraries I got from debian.org. JRiver folks did confirm that I wasn't missing any libraries which was good. Couldn't get past the segmentation fault so the app would never fire up. Could it be a permission problem? If so, I'd assume I'd get a different error. I defer to others as I'm in over my head. The great thing is that when I bork the image I just re-Etcher it and start anew. I've loosely documented what I've tried and eliminate/add different things but get the same result. My head hurts from banging it against the wall...might be approaching the whole insanity thing.  Big Grin The worst thing is that I still believe at some point I had the armhf version running on the stretch build but I can't reproduce it. Tinker, sailor, soldier, spy. I'll keep playing till I die!

Dunno as being wrong is great news for me as since the Arm Suse (SLES 64 bit) I had it in my head that Arm was not a simple matter for 32 & 64 bit and been planning on hitting compiling needs for some of the stuff I want to do with the Rock.

The segfault is memory addressing I think and it sort of does sound like maybe a call or lib is maybe 32/64 whilst maybe should be 64/32.
Eagerly did a bit of reading after this.

Have you done an apt-get update and apt-get upgrade after dpkg --add-architecture armhf ?

Apols as that is great to know, still scratching my head maybe it was just me and SLES as been certain I would have to compile Arm64 apps where they didn't exist.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  irradium (based on crux linux) Rock64 riscv64, aarch64 mara 0 53 03-24-2024, 01:07 PM
Last Post: mara
  Rock64 v2 - did not work song / audio sqw200zu 2 1,237 03-14-2024, 03:09 AM
Last Post: dmitrymyadzelets
  Rock64 won't boot dstallmo 0 243 12-27-2023, 10:34 AM
Last Post: dstallmo
  HDMI doesn't work on rock64 Noung1991 1 511 11-21-2023, 08:33 AM
Last Post: as365n4
  Rock64 + Klipper + KlipperScreen Instructions godzilla62 0 512 10-22-2023, 01:52 AM
Last Post: godzilla62
  Rock64 Debian 11 (Bullseye) install problem jbize 15 7,966 10-12-2023, 05:14 PM
Last Post: tpaul
  slarm64 (unofficial slackware) Rock64 RK3328 (aarch64) mara 133 186,455 10-09-2023, 03:31 AM
Last Post: mara
  arch rock64 does not boot nemnob 0 510 07-09-2023, 03:28 AM
Last Post: nemnob
  RXDP from Win10 to Armbian on Rock64 Transportsicherung 0 564 05-27-2023, 06:11 AM
Last Post: Transportsicherung
  DietPi OS for ROCK64 MichaIng 41 31,744 12-07-2022, 08:22 PM
Last Post: luminosity7

Forum Jump:


Users browsing this thread: 1 Guest(s)