Make a 64 bit versions

[frog-o]

I was play with the source for this when it was young. I was trying to split it into a lib. So I could do 2 things

1. make a 64 bit version (why because i want to run and build android program and you need a 64 bit arm)
2. learn the source an inner working on how all this works in assembly

I see now though you already made it a library so i would like to say

Thank-you

for that.

I wanted to know your thought on a 64 bit build you said it won't build on 64bit but

• will you be open to changes that allow it to build
• what would be required to add such support
• would it be a lot to of work to add the reference book white paper links etc.. you used to the readme.

Note:

• I don't have much for time and I don't want to wast yours but I think the above could be very useful and thought you might want to share your insight and I would rely like to hear it.

• I accidentally got into to big off a hurry. I rely like the work you put into this :) and I post this before I should sorry :( I am edit it now (as I go) trying to make it more relevant.

I want to start work on thing asp an I was not thinking to see what has changed over the years and made the mistake of looking at issue first and not the source code and readme.

[ptitSeb]

I'm unsure I understand your question. But, point 1: box64 exist now: https://github.com/ptitSeb/box64 point 2: box86 can already be built as library, but I think it's not what you are looking for.

Don't think of box86 as you everyday emulator like muppen64, snes9x, or other regular console/computer emulator. Box86 doesn't have any GUI, and even has very limited console interaction because it's not supposed to be used directly. The objective have always be to have box86 "part of the system" and beeing launch in a transparent way. Similar to how qemu-user is used, but more easily (mainly because it doesn't need a full chroot to run)

[frog-o]

I did not aspect you to reply so fast I edited my original post to make thing more relevant. Box 86 is exactly what i looking for but it needs 64 bit support.. I would like to do such thing on my pi4 (which is only supported on amd64 bits) such as

• run android build tools
• run chromium so i can sync
• run brave

I am just look for the reference you used to build box86 and ask for 64bit support ( a feature request ,something i wanted to try to help develop) I want to get near native performance and your method is the only way to do this that i am aware off.

I think this method is genius. Sorry again and thankyou.

[frog-o]

I need to slow down add start reading things more closely . I thought you said box86 lib exist now could you add "if you are look for 64 bit support check out the box64 to you readme and close this commit.

[ptitSeb]

I added some precision about box64 in the readme.

Box86 can be built as a lib yes. The purpose was to be able to wrap an x86 (closed source) library so it can be run using ARM programs. I never publicly used it and show how to do, I just did some private experiementation. But again, I don't think it's really what you want (but I'm not sure, just guessing here, also, that "lib" build is not available in box64)

[MichaIng]

Probably related, we're stuck on getting Steam running on an aarch64 system.

• Box64 compiles and runs fine, but Steam frontend is i386 which is not supported by Box64.
• Box86 seems to be very difficult to build and run on aarch64, I guess aside of the whole cross-compiling toolchain also all shared libraries used by Steam need to be present in armv7l format then so that Box86 can use them for the i386 binaries.
• Awesome would be if there was an Box86 version which translates i386 binaries into aarch64 and was able to also use aarch64 shared libraries for those binaries. I'm not sure whether this is possible at all or complete nonsense 😄. That way one could run Box86 and Box64 concurrently, without adding armv7l toolchain, libraries and packages, and run Steam with additional support for 64-bit games.

[ptitSeb]

• Awesome would be if there was an Box86 version which translates i386 binaries into aarch64 and was able to also use aarch64 shared libraries for those binaries. I'm not sure whether this is possible at all or complete nonsense 😄. That way one could run Box86 and Box64 concurrently, without adding armv7l toolchain, libraries and packages, and run Steam with additional support for 64-bit games.

Yeah, that "Box32", but it's not a thing yet. I need to do a POC first, but I need to have a more stable box64 first, and I need to do some research also...

[MichaIng]

Awesome that it is somewhere on the list already. Makes sense to give it an own title/project, not only to overload Box86 but also to avoid potential conflicts when wanting both for some reason, testing or development.

[leonpano2006]

My jetson have NON ARMHF OR ARMEL ONLY AARCH64

[frog-o]

when i open this and post. I quickly ran out of energy. I spent all my time writing and prof-reading. Later In the week i saw all these commit. I was not expecting so much. You guys are awesome.

I am really confused though ,with commit like this

Awesome would be if there was an Box86 version which translates i386 binaries into aarch64 and was able to also use aarch64 shared libraries for those binaries. I'm not sure whether this is possible at all or complete nonsense smile. That way one could run Box86 and Box64 concurrently, without adding armv7l toolchain, libraries and packages, and run Steam with additional support for 64-bit games.

I read a little on assembly; From what i understand 32-bit program run just fine on 64-bit the ,64-bit is an extension to 32-bit. From reading your code a long while back it sound like you where emulating these registers(loading the program in memorry has to be a lot different then running them). If you are emulating the 64-bit register you should be able to emulate the 32-bit one and what is POC. I will have to look all this up.

This is not very important, at least for now; It is clear I need to do more research on this, I think it would be awesome if you

1. Have a reference section on all web-site, book white paper etc. you use while building Box86 and Box64. I have not yet found a good reference on x86 assembly. Finding info is hard for me, It could be because I am cheep and don't like to buy books ,but IMHO it because books have to much info and don't play well with my poor comprehension.
2. List all the work need to merge box86 with box64( I would not want to try to emulate 64 bit on a 32-bit system)

Anyways thank-you I enjoyed reading the commits above even thought I can not understand them completely. ( I love puzzle : )

[MichaIng]

From what i understand 32-bit program run just fine on 64-bit

Yes they do and you can run Box86 compiled on an armv7l system perfectly fine on any aarch64 system, that is not the issue, but:

• You need to have an armv7l toolchain for cross-compiling Box86 on an aarch64 system, which makes it more difficult for many users and increases overhead/hurdles to get it running, when one does not have an armv7l system as well, flashes an armv7l OS temporarily or spins up a QEMU container.
• Since Box86 cannot use native aarch64 shared libraries with the i386 binaries, you usually need to install foreign architecture shared libraries, and multiarch packages (resp. installing libraries for different architectures on the same system) is not always easily possible.
• I guess performance would benefit when "Box32" knows in the first place that those i386 binaries and libraries are used on an aarch64 and can make translation more efficiently compared to i386 => armv7l => executed by aarch64.

So yes indeed it is mostly for convenience and to make it easier and faster to setup for average users. I guess performance is an aspect, but I cannot evaluate whether significant or not.

[frog-o]

Thank for more details MichaIng. Just for info

You need to have an armv7l toolchain for cross-compiling Box86 on an aarch64 system, which makes it more difficult for many users and increases overhead/hurdles to get it running, when one does not have an armv7l system as well, flashes an armv7l OS temporarily or spins up a QEMU container.

I think this maybe easy to setup then you realize I currently using

• A 32-bit os running a 64-bit kernel
  and use
• systemd-nspawn to launch a 64-bit debain

There is no emulation.

I have not tried to build box86 yet but I don't know why this won't work.

One thing I have not ask yet but (maybe I should of first) is

• Could we make A tar ball with all need files that one can just systemd-nspawn into and build box86.(systemd-nspawn is an advance chroot very easy to use)

Having a strip down os(32/64-bit) might be the key to solve these kinds of problem.

• If i tried and where able to make such a tarball would you guys be interested?

I done a quick look for issue on box86 and containers to see if this has been asked I found

Adding chroot mode #242 Problem with using box86 in docker container. #435 Dropbox in Box86 #30

and some other like this but not that question.

Since Box86 cannot use native aarch64 shared libraries with the i386 binaries, you usually need to install foreign architecture shared libraries, and multiarch packages (resp. installing libraries for different architectures on the same system) is not always easily possible.

I can't help but wonder since box86 is emulating the cpu if this is rely true. That the cool thing about with the twist what is stopping us from call a 64-bit lib from a 32-bit emulated app I need to look into this!(i have not done enough with c++ or assemble to know.)

So yes indeed it is mostly for convenience and to make it easier and faster to setup for average users. I guess performance is an aspect, but I cannot evaluate whether significant or not.

I don't think speed is an issue when containers is used(QEMU should not be needed).

I have a problem of think thing are simpler then what they are. I am not expecting any commit except for maybe a yes or no to the tarball question. I don't want to wast your time just food for thought As stated above I like reading about your thought and thanks.

[MichaIng]

Ah yes, erase "QEMU" from my last post and replace it with "Docker or systemd-nspawn". I meant this for the build only, not for running Box86. Also for the build, an armv7l container with CMAKE_HOST_SYSTEM_PROCESSOR (?) set to override uname -m should be fine. So yes the idea matches yours to have the toolchain in a container instead of installing it on the host system. Again, of course this is all possible, so having a BoxXY which natively builds on aarch64 to run i386 mostly makes it easier to build and run it.

About the performance aspect, from what I understand, Box86 translates i386 instructions directly into armv7l instructions, and then ships some internal i386 libraries and looks for armv7l libraries on the system when linked by the binary. I'm pretty sure it cannot use aarch64 libraries. It was only a guess that a direct translation into aarch64 + possibly some changed magic would allow better performance compared to translating into armv7l instructions first and have the aarch64 CPU then interpret them as such. But not sure if this is a point.

[frog-o]

You post:

Ah yes, erase "QEMU" from my last post and replace it with "Docker or systemd-nspawn". I meant this for the build only,

Sorry i did't mean to offed you ,Please remember i have problems with comprehension. I meant the docker system to be used just for the build also but I can see how it can also be used for running.

. So yes the idea matches yours to have the toolchain in a container instead of installing it on the host system. Again, of course this is all possible, so having a BoxXY which natively builds on aarch64 to run i386 mostly makes it easier to build and run it.

The bold is what i was tring to say and did not know you said it.

[joeyoropesa-dev]

Can this two Box86 and Box64 to be united so that from one of those projects can emulate both 64-bit and 32-bit support for aarch64

[ptitSeb]

Nope. The wrapping of function call prevent that. I have another project called box32 for running 32bits apps for 64bits OS, but it's just a private POC for now, and far from being usefull.

[DragonSWDev]

@ptitSeb Are there any updates about box32 project? Since some modern ARM SoC (for example Apple M series) are not capable of running 32 bit code natively and makes box86 unusable, box32 could help with that.

[ptitSeb]

@ptitSeb Are there any updates about box32 project? Since some modern ARM SoC (for example Apple M series) are not capable of running 32 bit code natively and makes box86 unusable, box32 could help with that.

No, not yet. I'll start working on that on the version.

[DragonSWDev]

@ptitSeb Thanks for the clarification.