View previous topic :: View next topic |
Author |
Message |
dinominant Tux's lil' helper
Joined: 27 Oct 2006 Posts: 102
|
Posted: Sat Sep 16, 2017 4:51 pm Post subject: How do I emerge a package for a foreign architecture? |
|
|
I have dynamic binary translation setup and working on my aarch64 host (Orange Pi PC2). I want to install a binary package that only has i386 and x86_64 binaries. Is there a way to unmask the i386 version of the package and force portage to install that one -- even though my architecture is different? If I just copy the files over it works, but I would rather have emerge manage the package then inject some binaries into my root filesystem.
The dynamic binary translation may be slow, but it actually works. Sometimes it's the only way.
Last edited by dinominant on Fri Sep 22, 2017 2:05 am; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sat Sep 16, 2017 5:24 pm Post subject: |
|
|
dinominant,
I don't fully understand what you want to do.
You want to run an existing i386/x86_64 binary on an aarch64 system using the binfmt service, or something like it.
If the program in statically linked (unlikely) then qemu should run it.
If its dynamically linked, you need to put it into a chroot, with all its libraries and a static-user QEMU built for the host and run it there.
If you want to, you can do an x32 or amd64 install in this chroot, with the aid of a static-user QEMU.
Like an arm64 chroot on an amd64 system but in reverse.
What's the program?
Its a whole lot less pain to build it for arm64. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
dinominant Tux's lil' helper
Joined: 27 Oct 2006 Posts: 102
|
Posted: Sat Sep 16, 2017 6:01 pm Post subject: |
|
|
I have a working aarch64 host, with qemu statically built. As a proof of concept I have previously setup an entire Gentoo i686 chroot with wine and SkiFree.exe on a raspberry pi 2, which actually worked.
However, in this particular situation I am building a high resolution network flatbed scanner with SANE (using the Epson Perfection V550 which is USB only). It has linux support, but only for x86 and amd64. So I want to use dynamic binary translation so I can use it on my aarch64 Orange Pi PC2. My project is to make the scanner fully autonomous so I can place an item, press the scan button on the Orange Pi, and let it run for hours while it performs a ultra high resolution scan to a network share. Later I plan to add some LED lights so I can try some multi spectral scanning.
The scanner works on my amd64 host perfecly. I want to get it working on arm and arm64. There are no open source drivers that I can build, only x86 and amd64 binaries: https://bugs.gentoo.org/580450 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sat Sep 16, 2017 7:09 pm Post subject: |
|
|
dinominant,
That will be iscan then. You will need to run it in a chroot with all the libs that Code: | lddtree /usr/bin/iscan | tells you it wants.
You can reduce that list with careful use of USE flags.
The iscan-2.30.1.1.ebuild suggests that some parts of the code are arch agnostic, so you may be be able to break it up and only
run parts of it in the chroot.
The V550 has an optical resolution of 6400x9600 DPI. There is no point in scanning above that as the extra data is interpolated.
That's a big word for "made up".
I've just got V600 and wondered about making it work from a arm64 Pi 3, so keep us posted. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sat Sep 16, 2017 9:47 pm Post subject: |
|
|
NeddySeagoon wrote: | ... the extra data is interpolated.
That's a big word for "made up". | More like "made an intelligent guess at". |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3445
|
Posted: Sat Sep 16, 2017 9:56 pm Post subject: |
|
|
This "intelligent guess" of yours inflates the data file even though it does not contain any new information.
Being useless, can safely be left out until the end user actually attempts to scale the whole image beyond its limits.
Well, "made up" feels way more honest to me. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sat Sep 16, 2017 10:15 pm Post subject: |
|
|
Tony0945,
There are any number of interpolation algorithms.
They all give different answers and they are all equally valid. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sat Sep 16, 2017 11:10 pm Post subject: ant m |
|
|
szatox wrote: | This "intelligent guess" of yours inflates the data file even though it does not contain any new information.
| I agree. However, there is a trade off between file size and processing time. For linear interpolation and modern CPU's, the processing time is usually trivial.
NeddySeagoon wrote: | Tony0945,
There are any number of interpolation algorithms.
They all give different answers and they are all equally valid. |
Quite right. Quadratic, exponential, and sinusoidal come to mind. But not all are equally valid. Interpolation is an important mathematical tool and although I smiled when I read your post, it is different from random guessing. Unless you have a formula to calculate exactly, the only basis for estimating non-measured data points is interpolation. |
|
Back to top |
|
|
dinominant Tux's lil' helper
Joined: 27 Oct 2006 Posts: 102
|
Posted: Sun Sep 17, 2017 6:22 am Post subject: |
|
|
I went ahead and tried two approaches with the media-gfx/iscan-plugin-perfection-v550 package (this package works fine on my amd64 host without any chroot or binary translation).
Plan A: installing the i386 package directly on the arm host with qemu dynamic binary translation
With this configuration I modified the media-gfx/iscan-plugin-perfection-v550 ebuild to just install the i386 files.
I am able to run scanimage, but actually scanning does not work.
Code: | scanner # scanimage -L
device `epkowa:interpreter:005:002' is a Epson (unknown model) flatbed scanner |
Code: | scanner # scanimage --format tiff --progress --mode Color --depth 8 --resolution 800 -l 0 -t 0 -x 10 -y 10 >test.tiff
scanimage: open of device epkowa:interpreter:005:002 failed: Invalid argument |
Plan B: i386 chroot on the arm host with dynamic binary translation
I am able to run scanimage, but actually scanning does not work. There are a few unsupported ioctl messages too:
Code: | scanner # scanimage -L
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x41045508
Unsupported ioctl: cmd=0x8004550f
qemu: Unsupported syscall: 101
device `epkowa:interpreter:005:002' is a Epson (unknown model) flatbed scanner |
Code: | scanner # scanimage --format tiff --progress --mode Color --depth 8 --resolution 800 -l 0 -t 0 -x 10 -y 10 >test.tiff
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x41045508
Unsupported ioctl: cmd=0x8004550f
qemu: Unsupported syscall: 101
Unsupported ioctl: cmd=0x8004551a
Unsupported ioctl: cmd=0x41045508
Unsupported ioctl: cmd=0x8004550f
scanimage: open of device epkowa:interpreter:005:002 failed: Invalid argument |
Searching on google for 0x41045508 I found that qemu might be missing some libusb support that would allow this type of a configuration to work: https://lists.nongnu.org/archive/html/qemu-discuss/2013-07/msg00046.html
I guess I'll need to try Plan C, which is to run a full i386 vm on the orange pi and pass the scanner usb device to the guest vm. Hopefully this will be fast enough and actually work. I do not have KVM enabled, and afak that doesn't even work when emulating a different architecture. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Sun Sep 17, 2017 8:56 am Post subject: |
|
|
dinominant,
The scanner needs a firmware upload that is provided by the binary plugin.
The iscan ebuild hints that iscan itself is arch agnostic but the plugins are not.
As the scanner has its own PSU, it may be enough to run iscan with the plugin on a real 32 or 64 bit system, then move the USB over to the arm64, without powering down.
The firmware will still be loaded. Its a long shot but worth a try. It all depends what the plugin does. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
dinominant Tux's lil' helper
Joined: 27 Oct 2006 Posts: 102
|
Posted: Fri Sep 22, 2017 2:17 am Post subject: |
|
|
Plan C, which is to run a full i386 vm on the orange pi and pass the scanner usb device to the guest vm... also failed.
Something is very broken with either Qemu, the armbian kernel for the orange pi pc2 I'm using, or both. When I boot the qemu virtual machine without a network adapter I can start the gentoo installation, but if I try to boot it with a network adapter connected to br0 I get a kernel panic as soon as I power on the virtual machine and then the orange pi restarts.
I'm going to start off with an old junk x86_64 laptop first. Then I'm going to try running an armv7hf virtual machine on that with an updated vanilla-sources kernel to see if that works. This way I can eliminate the non-standard orange/raspberry pi kernels and their "stable" drivers from the equation. It's going to be fantastically slow (x86_64-> Qemu -> armv7hf guest -> qemu dynamic translation for the x86_32 scanner parts), but I'm curious if that will work. |
|
Back to top |
|
|
|