x86 on the Raspberry Pi with jessie chroot

[code_exec]

I was able to run x86 programs on my RPi3 with a x86 Debian Jessie chroot. What a chroot does is it basically takes you into another file system. Thanks to qemu-user-static (which allows you to chroot into Linux environments compiled for different architectures), I was able to chroot into an i386 Debian Jessie environment (amd64 doesn't work at the moment). I was able to run the i386 version of Pluma successfully. The problem is, when I attempted to save my file, Pluma crashed with a Segmentation fault (I'm not entirely sure, but I believe it is related to the fact that the Pi uses a 2g/2g memory split rather than a 3g/1g memory split).

If someone could give me advice on how to enable 3g/1g memory split, I'd appreciate it. Thanks.

[DougieLawson]

Forget it. It won't work.

If you insist on running code from an alien architecture you're going to have to bite the bullet and pay the Eltechs folks for their optimised X86 emulator.

https://eltechs.com/product/exagear-desktop/

A better prospect is to buy a cheap secondhand laptop (from eBay), reformat the hard disk, load up Ubuntu on it and run your X86 programs on an X86 machine not on a Raspberry

[code_exec]

Forget it. It won't work.

If you insist on running code from an alien architecture you're going to have to bite the bullet and pay the Eltechs folks for their optimised X86 emulator.

https://eltechs.com/product/exagear-desktop/

A better prospect is to buy a cheap secondhand laptop (from eBay), reformat the hard disk, load up Ubuntu on it and run your X86 programs on an X86 machine not on a Raspberry

Eltechs' ExaGear is essentially chroot but with a few tweaks made. If I was able to start up Pluma for x86 in a chroot environment, then running x86 on the Pi is possible, but not very stable.

[davidcoton]

You cannot run x86 code on a Pi without an emulator, which is what Exagear is.

If your "Pluma" is this MATE editor, then it is a Python program, not x86 code. Your "chroot" might provide an environment in which Python code written on on x86 Ubuntu Mate will run, but it is not enabling x86 code.

[code_exec]

You cannot run x86 code on a Pi without an emulator, which is what Exagear is.

If your "Pluma" is this MATE editor, then it is a Python program, not x86 code. Your "chroot" might provide an environment in which Python code written on on x86 Ubuntu Mate will run, but it is not enabling x86 code.

Hmmm, I see. However, with qemu-user-static, it is possible to chroot into filesystems for different architectures. Whether or not that enables running code for different architectures I do not know.

https://wiki.debian.org/QemuUserEmulation

[hippy]

If your "Pluma" is this MATE editor, then it is a Python program, not x86 code.

I am not sure it is Python code but if it is the MATE Editor then it can be installed on a Raspbian Stretch Pi with -

sudo apt-get install pluma

It even automatically appears as an option on the desktop start menu under accessories.

[code_exec]

If your "Pluma" is this MATE editor, then it is a Python program, not x86 code.

I am not sure it is Python code but if it is the MATE Editor then it can be installed on a Raspbian Stretch Pi with -

sudo apt-get install pluma

It even automatically appears as an option on the desktop start menu under accessories.

I'm aware, I was just using it as a testing program.

[davidcoton]

I am not sure it is Python code...

On looking again, you are right. I read the github page too quickly. I think it is C/C++, but it is compiled on the target when installed.
In any case you are NOT executing x86 code on a Pi.

However, with qemu-user-static, it is possible to chroot into filesystems for different architectures.

Correct.

Whether or not that enables running code for different architectures I do not know.

It provides the environment for code from a diiferent OS -- so a Windows program can run on Linux, for example.
It does not provide emulation for code from a different architecture. You cannot run x86 code directly on a Pi, which has an Arm processor.

[code_exec]

It provides the environment for code from a diiferent OS -- so a Windows program can run on Linux, for example.
It does not provide emulation for code from a different architecture. You cannot run x86 code directly on a Pi, which has an Arm processor.

You can only chroot into other Linux distros, not into Windows.

If x86 programs can't run on ARM through Chroot because of architecture issues, then what causes programs to give a "segmentation fault" rather than an error about architecture.

According to Wikipedia:

In computing, a segmentation fault (often shortened to segfault) or access violation is a fault, or failure condition, raised by hardware with memory protection, notifying an operating system (OS) the software has attempted to access a restricted area of memory (a memory access violation).

[code_exec]

Also, on my x64 laptop, I was able to run ARM64 Chromium under a chroot and it launched. However, it was slow, and couldn't load any webpages.

[mikerr]

The main thing is qemu which is used to emulate x86 on the pi.

Exagear is essentially an x86 chroot install with a modified/optimized qemu and wine(if using Windows apps)

You need to compile your own kernel for 3/1 memory split.

Also have a prebuilt image here:
https://github.com/mikerr/RPi-QEMU-x86- ... /README.md
https://sourceforge.net/projects/pi-qemu-wine/

[code_exec]

The main thing is qemu which is used to emulate x86 on the pi.

Exagear is essentially an x86 chroot install with a modified/optimized qemu and wine(if using Windows apps)

You need to compile your own kernel for 3/1 memory split.

Also have a prebuilt image here:
https://github.com/mikerr/RPi-QEMU-x86- ... /README.md
https://sourceforge.net/projects/pi-qemu-wine/

I recompiled the kernel for 3G/1G memory split.

I'm trying to run WINE under a Debian Jessie chroot. However, when I try to setup WINE through wineboot, I get the following error:

Code: Select all

/bin/cat: /root/.wine/system.reg: No such file or directory
/usr/bin/wineboot: 32: exec: wineboot.exe: not found

I try running winecfg, and get:

Code: Select all

/usr/lib/i386-linux-gnu/wine/bin/wine-preloader: Unable to find space for application

Raspbian is installed on a 32GB microSD card, and I still have 20GB left.

Any ideas on how to fix this?

[ejolson]

Any ideas on how to fix this?

I find this thread interesting because of the posts which confidently say something can't be done along with a near equal number of posts explaining how to do it. Running x86 code on ARM is also what Microsoft has said will be possible with their new ARM based version of Windows. It's interesting to see how well x86 emulation currently performs using open source tools.

While I don't have anything other than enthusiasm to contribute, I was wondering whether current versions of QEMU support emulation of multiprocessor x86 systems?

[fruitoftheloom]

Any ideas on how to fix this?

I find this thread interesting because of the posts which confidently say something can't be done along with a near equal number of posts explaining how to do it. Running x86 code on ARM is also what Microsoft has said will be possible with their new ARM based version of Windows. It's interesting to see how well x86 emulation currently performs using open source tools.

While I don't have anything other than enthusiasm to contribute, I was wondering whether current versions of QEMU support emulation of multiprocessor x86 systems?

The OP has a NEW post:

viewtopic.php?f=41&t=226376

[code_exec]

Any ideas on how to fix this?

I find this thread interesting because of the posts which confidently say something can't be done along with a near equal number of posts explaining how to do it. Running x86 code on ARM is also what Microsoft has said will be possible with their new ARM based version of Windows. It's interesting to see how well x86 emulation currently performs using open source tools.

While I don't have anything other than enthusiasm to contribute, I was wondering whether current versions of QEMU support emulation of multiprocessor x86 systems?

x86 on ARM is possible thanks to qemu-user-static.

Don't believe me?

[mikerr]

Nothing new, you're treading the same steps we did in 2012ish...
viewtopic.php?f=41&t=12727
Follow that thread to see how it's done, but some patches will have been integrated into qemu by now.

(And lots of posters moaned it wasn't possible or would be too slow then, too)
It's better with pi3 but still slow.

[code_exec]

Nothing new, you're treading the same steps we did in 2012ish...
viewtopic.php?f=41&t=12727
Follow that thread to see how it's done, but some patches will have been integrated into qemu by now.

(And lots of posters moaned it wasn't possible or would be too slow then, too)
It's better with pi3 but still slow.

Sorry for late reply, I only just noticed this.

It appears that WINE on the Pi in 2012 could run apps that could run on Windows RT and Windows CE (both versions of Windows made for ARM processors), and there aren't many of those. Pi386, however, lets you run 32-bit x86 software on your Pi, including WINE. Since Pi386 is an emulation layer, the version of WINE you use on it is compiled for the i386 architecture and therefore allows execution of 32-bit x86 Windows software on the Pi.

[jdonald]

Hey code_exec, just wanted to lend my support to cheer you on. It's great that you're doing this.

It appears that WINE on the Pi in 2012 could run apps that could run on Windows RT and Windows CE (both versions of Windows made for ARM processors), and there aren't many of those. Pi386, however, lets you run 32-bit x86 software on your Pi.

I'm catching up on the old threads too. Although the first page you cite is largely about Wine+ARM, page 2 and beyond are discussing and building wine:i386.

Of course, even if the fundamental mechanisms haven't changed much as mikerr points out, over time it can be a huge difference making things more convenient and accessible to the everyday user. I see aspects such as having much faster hardware than 2012, mikerr's img file, and your tool as all part of this.

Now for some suggestions:

* We haven't escaped requiring a modified kernel. Even if your distribution makes it easier to update this, it's a hassle to maintain alongside official kernel updates and at the very least a reboot is required to install. This has probably been suggested in the past, but what are the downsides if the Raspbian maintainers were to make 3G/1G the official default?

* If the above is a no-go, I think Eltech modified wine:i386 such that the 3G/1G split isn't required. Could we standardize a build of that branch of wine:i386 or maybe even get the changes pushed upstream?

While I don't have anything other than enthusiasm to contribute, I was wondering whether current versions of QEMU support emulation of multiprocessor x86 systems?

* I think he's asking you about trying qemu with the -smp arg. Given much of the pre-2000 software that we're running here is single-threaded it's debatable how much we'd get out of this, but would be good to answer.

* Any speedups or at least compatibility improvements if we use the latest wine from winehq-staging?

* In notaz's Diablo II build I see all these flags like WINE_SND_FORCE_RATE, WINE_FBDEV_VSYNC, WINE_FBDEV_DOUBLEBUF, WINE_FBDEV_USE_SCALER, WINE_DDRAW_NO_FLIP_CAP, WINE_DDRAW_NO_FRONT_BLIT. Has anyone found these to improve performance outside of Diablo II?

[mikerr]

Pi386, however, lets you run 32-bit x86 software on your Pi, including WINE. Since Pi386 is an emulation layer, the version of WINE you use on it is compiled for the i386 architecture and therefore allows execution of 32-bit x86 Windows software on the Pi.

You should really mention it's QEMU that is actually providing x86 emulation, not "pi386" as opposed to bochs, dosbox etc