Log In  

Are there any plans to support the ARM64 architecture? 64-bit OSes for the Raspberry Pi and other boards are becoming more popular, and at present the only way to run PICO-8 on a 64-bit Pi OS is to install Raspbian in a chroot, use a hack in the .Xauthority file, and run PICO-8 from within the chroot.

That is not a satisfactory solution. No OSes exist for the Pi that have a mixed userland (Raspbian is 32-bit only) so the most practical solution is to put together an ARM64 build for PICO-8.

If you don't have easy access to a 64-bit image to build on, there is one based on Gentoo that comes with a desktop and toolchain out of the box: https://github.com/sakaki-/gentoo-on-rpi-64bit

Only you have the source code, @zep! What do you think? :P

P#71918 2020-01-14 03:36

+1, now that I know this is an issue anyway. There's also a usable image of Ubuntu Server here:

https://jamesachambers.com/raspberry-pi-4-ubuntu-server-desktop-18-04-3-image-unofficial/

I think the latest official distro of 19.10.x is fairly complete in its support for RPi4 in arm64 mode too, but I haven't tried it myself yet.

P#71919 2020-01-14 03:45 ( Edited 2020-01-14 03:53)
:: Felice
2

(Psst catatafish, if you really want to +1, that's what the star button on the right of each post is for.)

P#71974 2020-01-15 23:40
:: zlg
1

I did some digging. Distros that enable 32-bit support in the kernel for their ARM/RPi builds should be able to run a 32-bit static binary without a 32-bit userland.

I also noticed that both pico8 and pico8_dyn are dynamically linked in the pi download. The former is stripped, but not static. So the hardware may support it, but the binary wasn't built statically, so it looks for the 32-bit armhf loader, which won't work on an aarch64 userland without building a multilib system (of which nobody does at the time of writing due to 32-bit ARM arch fragmentation and the looming 2038 problem).

So, fixing it to be static can be a good interim solution while aarch64 is being looked into. It would at least give us a way to run it in a 64-bit userland.

While I did this I checked the x86_64 version of PICO-8 and both ./pico8 and ./pico8_dyn are dynamically linked there, too:

pico8

$ readelf -d ./pico8

Dynamic section at offset 0x24fa50 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x403680
 0x000000000000000d (FINI)               0x5d9894
 0x0000000000000019 (INIT_ARRAY)         0x84e150
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x84e158
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x400298
 0x0000000000000005 (STRTAB)             0x401720
 0x0000000000000006 (SYMTAB)             0x4002e0
 0x000000000000000a (STRSZ)              2113 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x851000
 0x0000000000000002 (PLTRELSZ)           4992 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x402300
 0x0000000000000007 (RELA)               0x402228
 0x0000000000000008 (RELASZ)             216 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x402118
 0x000000006fffffff (VERNEEDNUM)         5
 0x000000006ffffff0 (VERSYM)             0x401f62
 0x0000000000000000 (NULL)               0x0

pico8_dyn

readelf -d ./pico8_dyn

Dynamic section at offset 0x114dc8 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libSDL2-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4035f0
 0x000000000000000d (FINI)               0x4dc454
 0x0000000000000019 (INIT_ARRAY)         0x713fd0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x713fd8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x400298
 0x0000000000000005 (STRTAB)             0x401668
 0x0000000000000006 (SYMTAB)             0x4002e8
 0x000000000000000a (STRSZ)              2696 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x715000
 0x0000000000000002 (PLTRELSZ)           4680 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x4023a8
 0x0000000000000007 (RELA)               0x402330
 0x0000000000000008 (RELASZ)             120 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x402290
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x4020f0
 0x0000000000000000 (NULL)               0x0

(Perhaps I'm misunderstanding the intended distinction between pico8 and pico8_dyn.. clarification would be appreciated)

P#72200 2020-01-25 00:03 ( Edited 2020-01-25 02:37)

Can't really comment on the ABI details as I don't know the arm platform at all, but (and I should really get off my butt and check this stuff for myself but I don't have much time at the moment) I remembered that Ubuntu 19 also supports KVM, if you can live with virtualization that may be another interim option.

Also thanks Felice, I wasn't thinking of stars as +1's (more like bookmarks), but I've clicked the appropriate places now.

P#72226 2020-01-25 01:16
:: zlg

@Catatafish: It should really only be an addition of a build target in whatever build system @zep uses to build PICO-8. AFAIK every major build system supports aarch64. Then (maybe) a change to how 'pico8' gets built so it produces a static binary. We'd run into fewer linking issues because customers could fall back to the static binary if there's an issue with their system.

The devil's in the details: it adds to the maintenance burden (if only a little) and it's another build target to test, another download link, etc. Maybe it's not a problem, since the PocketCHIP still gets PICO-8 builds and it's dead hardware. (not meant as a pejorative; they look fun and it's a shame it's not a thing anymore)

EDIT: I hear you on time constraints! So many things I want to do in PICO-8, never enough time. :)

P#72228 2020-01-25 02:48 ( Edited 2020-01-25 02:52)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-02-19 20:08 | 0.016s | 4194k | Q:25