search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.81k stars 494 forks source link

DietPi-Software | Amiberry: Add support for Buster and RPi4 #3104

Closed TuKo1982 closed 4 years ago

TuKo1982 commented 5 years ago

Can't install AmiBerry package on latest DietPi Buster (Pi4)

Installer complains that libsndio6.1 has no installation candidate and exits with error code 100.

MichaIng commented 5 years ago

@TuKo1982 Many thanks for reporting.

Will have a look and in case update the pre-req package to a Buster-matching version.

Okay, I updated the library package for Buster support: https://github.com/MichaIng/DietPi/commit/4886c55fc89fb5286300f265ef2988936a776958 (Changelog: https://github.com/MichaIng/DietPi/commit/80c710c4f22f3e43d0f420389fb90a848e1e6874) But support for RPi4 is still outstanding, since we need to compile an SDL2 + DispmanX binary for it. See:

MichaIng commented 5 years ago

@midwan Or do you plan to ship a release with pre-compiled RPi4 SDL2 + DispmanX binary anyway or have one that you can send us?

I just don't have an RPi4 here, but otherwise will ask @Fourdee .

Another unimportant question: Do you prefer "AmiBerry" or "Amiberry"? :smiley: I'm aligning naming + capitalisation where required, in case of Amiberry I am just not sure whether to follow the logo with capital B or the text/docs etc with non-capital b.

midwan commented 5 years ago

@MichaIng I'm currently testing a (rather big) update of Amiberry for the next release, but I've updated the Makefile in master to include an RPI4 target. So that can already be used, and I could send you binaries if you like.

Of course, you'd still need SDL2 in the system as well as the other dependencies (they haven't changed, but SDL2 has seen several updates with bugfixes). SDL2 still needs to be compiled from source if you want to get KMSDRM support, for launching things full screen from the console. DispmanX is still there in Buster, and the FKMS driver is used by default, so there's no issue.

Regarding the naming: I'd prefer "Amiberry", even though the logo doesn't indicate that. The logo was designed in the early days of the project, and is due for an update however. :)

MichaIng commented 5 years ago

@midwan

I'm currently testing a (rather big) update of Amiberry for the next release

That sounds great :+1:.

So that can already be used, and I could send you binaries if you like.

Would be very kind. Just send to: micha_at_dietpi.com

Of course, you'd still need SDL2 in the system as well as the other dependencies (they haven't changed, but SDL2 has seen several updates with bugfixes).

We have some pre-compiled SDL2 package for x86_64, ARMv6+7, that we install together with Amyberry + dependencies of course. Although it sounds like they should be re-compiled by times as well. Will do that for x86_64 and ARMv7 at least.

Regarding the naming: I'd prefer "Amiberry", even though the logo doesn't indicate that. The logo was designed in the early days of the project, and is due for an update however. :)

I though so, so the guess/change with last commit was correct then.

midwan commented 5 years ago

I've updated the ZIP archive over at https://github.com/midwan/amiberry/releases/tag/v2.25 to include RPI4 binaries as well now.

The rest of the package remains the same, until the new beta is ready for release - then we'll merge from dev to master and provide new binaries as well.

MichaIng commented 5 years ago

I added the binary to our archive as well, however CloudFlare caching leads to currently the download still serves the old archive. Made some other minor enhancements, e.g. removing the obsolete adfdir.conf as well as amiberry.conf if existent (reinstall), to allow Amiberry recreating it as recommended, and removing non-required binaries and capsimg.so files to keep the dir slim and clean. Also updated autostart and online docs to match Amiberry (non-capital "b") and some other minor wording.

Commit DietPi-Software: https://github.com/MichaIng/DietPi/commit/b12918204e9cb372ddc014964fc04374da799669#diff-d92a6ee04e02fd2a2dc23d5bec3e6a98L8474-R8381 DietPi-Autostart: https://github.com/MichaIng/DietPi/commit/0359adafcf90da1f04dcfaf2922e158d36e6b0fa Online docs: https://dietpi.com/phpbb/viewtopic.php?p=64#p64

And I recognised now that our Amiberry RPi image is actually not really pre-installed. It only has Amiberry marked for automated install on first boot + related fast boot autostart option (via dietpi.txt). Otherwise it is a standard RPi image. This makes it very easy to update based on current RPi4-capable Buster + DietPi v6.25 image.

@midwan https://blitterstudio.com/amiberry/ requires a tiny update then for the new Buster archive and since we have changed how WiFi must be configured for first boot:

But I need to test our SDL2 on Buster first. EDIT: Installs fine, binaries execute fine. Nevertheless updated binaries make sense by times.

midwan commented 5 years ago

@MichaIng Thanks for the update! Regarding the file cleanup: capsimg.so is actually required if you want to be able to load *.ipf files in the emulator, so it's best to leave it in place. :)

One more thing to look for, since we're doing this: https://github.com/midwan/amiberry/issues/514

Perhaps this can be fixed with the new Buster-based image?

MichaIng commented 5 years ago

@midwan

Regarding the file cleanup: capsimg.so is actually required if you want to be able to load *.ipf files in the emulator, so it's best to leave it in place. :)

It is left in place. We ship three of them, for RPi, for Asus TB and for Odroid XU4. The matching one is moved/renamed, the other ones are removed. Same for the binaries:

# $amiberry_filename e.g. matches amiberry-rpi4-sdl2-dispmanx
mv "$G_FP_DIETPI_USERDATA/amiberry/$amiberry_filename" $G_FP_DIETPI_USERDATA/amiberry/amiberry
# $capsimg_filename e.g. matches capsimg-rpi.so
mv "$G_FP_DIETPI_USERDATA/amiberry/$capsimg_filename" $G_FP_DIETPI_USERDATA/amiberry/capsimg.so
# Only amiberry-* and capsimg-* (with dash) are removed
rm $G_FP_DIETPI_USERDATA/amiberry/{amiberry,capsimg}-*

One more thing to look for, since we're doing this: midwan/amiberry#514

Could be: https://github.com/MichaIng/DietPi/pull/2718 However this was resolved with v6.23 already. However further debug over there 🙂.

TuKo1982 commented 5 years ago

Ok, package is now installing correctly with 6.26. Amiberry binary needs probably a recompile against new libsndio7 and autostart script might also need some love.

MichaIng commented 5 years ago

@TuKo1982 Many thanks for testing!

binary needs probably a recompile against new libsndio7

It would make things too complicated (and too much effort) if we created different binaries for each distro version (<< different libsndio versions), IMO.

and autostart script might also need some love.

What you suggest?

The service that is started in every case:

[Unit]
Description=Amiberry Amiga Emulator (DietPi)

[Service]
#StandardOutput=tty
#StandardInput=tty
#TTYPath=/dev/tty1
#TTYReset=yes
#TTYVHangup=yes
WorkingDirectory=$G_FP_DIETPI_USERDATA/amiberry
ExecStart=$xinit_start$G_FP_DIETPI_USERDATA/amiberry/amiberry -f $G_FP_DIETPI_USERDATA/amiberry/conf/autostart.uae

[Install]
WantedBy=local-fs.target

The autostart.uae:

config_description=UAE default configuration
config_hardware=true
config_host=true
config_version=3.6.0
amiberry.cd_path=/mnt/dietpi_userdata/amiberry/cd32/
amiberry.hardfile_path=/mnt/dietpi_userdata/amiberry/
amiberry.floppy_path=/mnt/dietpi_userdata/amiberry/disks/
amiberry.rom_path=/mnt/dietpi_userdata/amiberry/kickstarts/
;
; *** Controller/Input Configuration
;
joyport0=mouse
joyport0_autofire=none
joyport0_friendlyname=Mouse
joyport0_name=MOUSE0
;
joyport1=joy0
joyport1_autofire=none
joyport1_friendlyname=Keyboard as Joystick [Default]
joyport1_name=JOY0
;
;
;
input.joymouse_speed_analog=2
input.joymouse_speed_digital=10
input.joymouse_deadzone=33
input.joystick_deadzone=33
input.analog_joystick_multiplier=15
input.analog_joystick_offset=-1
input.mouse_speed=100
input.autofire_speed=0
kbd_lang=us
;
; *** Host-Specific
;
amiberry.vertical_offset=0
amiberry.hide_idle_led=0
amiberry.gfx_correct_aspect=1
amiberry.kbd_led_num=-1
amiberry.kbd_led_scr=-1
amiberry.scaling_method=-1
amiberry.use_analogue_remap=false
amiberry.use_retroarch_quit=true
amiberry.use_retroarch_menu=true
amiberry.use_retroarch_reset=false
;
; *** Common / Paths
;
use_gui=yes
kickstart_rom_file=/mnt/dietpi_userdata/amiberry/kickstarts/ru/Kickstart v2.04 rev 37.175 (1991)(Commodore)(A500+).rom
kickstart_rom_file_id=C3BDB240,KS ROM v2.04 (A500+)
kickstart_ext_rom_file=
flash_file=
cart_file=
;
; *** Floppy Drives
;
floppy0=/mnt/dietpi_userdata/amiberry/floppy_images/Frontier - Elite II_Disk1.adf
floppy1=
floppy2=
floppy3=
nr_floppies=2
floppy_speed=800
;
; *** Hard Drives
;
;
; *** CD / CD32
;
cd_speed=100
;
; *** Display / Screen Setup
;
gfx_framerate=0
gfx_width=640
gfx_height=256
gfx_refreshrate=50
gfx_refreshrate_rtg=50
gfx_lores=false
gfx_resolution=hires
gfx_linemode=none
gfx_fullscreen_amiga=true
gfx_fullscreen_picasso=true
ntsc=false
;
; *** CPU options
;
cpu_speed=max
cpu_type=68000
cpu_model=68000
cpu_compatible=true
cpu_24bit_addressing=true
fpu_no_unimplemented=true
fpu_strict=false
compfpu=true
cachesize=0
;
; *** Memory
;
chipmem_size=2
z3mapping=real
fastmem_size=4
a3000mem_size=0
mbresmem_size=0
z3mem_size=0
z3mem_start=0x40000000
bogomem_size=0
rtg_modes=0x502
;
; *** Chipset
;
chipset=ecs
chipset_refreshrate=50.000000
collision_level=playfields
chipset_compatible=A500+
rtc=MSM6242B
cia_todbug=true
immediate_blits=false
waiting_blits=automatic
fast_copper=false
;
; *** Sound Options
;
sound_output=exact
sound_channels=stereo
sound_stereo_separation=7
sound_stereo_mixing_delay=0
sound_frequency=44100
sound_interpol=none
sound_filter=off
sound_filter_type=standard
sound_volume_cd=0
;
; *** Misc. Options
;
bsdsocket_emu=false

I am open for suggestions, since I don't actively use Amiberry, I have not much experience or knowledge about what works well and has which effect here 😉. I will also ask @Fourdee do to some review when he finds time.

MichaIng commented 5 years ago

Still an issue on Debian/Raspbian Buster: The binaries (or SDL2) need to be compiled against libsndio7.0 indeed, otherwise fail to start. Will see if we install the old libsndio6.1 package hosted on our server for now, otherwise a doubled set of pre-compiled binaries is required.

midwan commented 5 years ago

@MichaIng Why not just re-compile for Buster anyway, instead of keeping older libs around? It seems the most sane option going forward to me... :)

MichaIng commented 5 years ago

@midwan Okay, I actually wanted to postpone this to get v6.26 released as soon as possible, but maybe it makes sense to get this fully finished now.

So SDL2 needs to be recompiled, once for ARMv7 and once for the RPi1/Zero armv6hf. We allow SDL2 install via dietpi-software as well for x86_64, however this is easiest and the way I re-validate dependencies, build process etc. first anyway.

I will not touch the Stretch versions anymore, since those are still working and we will not offer Stretch images anymore, besides for XU4 currently, but not for long.

I just revisited your SDL2 compilation Wiki and the one from libsdl.org, and I am wondering why we actually compiled it with libsndio? DietPi comes by default with ALSA (libasound2) when audio is enabled, which is done as well when installing Amiberry. Are you aware of any reason why SDL2 should be compiled with sndio support when using ALSA for audio? So far I would compile it with --enable-alsa and --enable-video-kmsdrm only, disabling everything else actively or have it skipped by not installing the related library-dev packages. This version of SDL2 is for Amiberry on DietPi only, for everything else, one can simply install the repo packages. So no need to add any extra support that is not used by our setup.

midwan commented 5 years ago

@MichaIng Hm, I'm not sure, I personally never had to enable/disable anything else besides the options specified in our wiki also: https://github.com/midwan/amiberry/wiki/Compile-SDL2-from-source

Basically the only reason we need to compile from source and not use the repo provided binaries, is the option --enable-video-kmsdrm. Otherwise it comes with --enable-video-rpi and with KMSDRM disabled, by default.

MichaIng commented 5 years ago

@midwan Jep these two options would be sufficient of course, but disabling other unused features should reduce the dependencies/libraries (like libsndio) the binary needs to start. I found some older SDL2 binaries that are not installed anymore (https://dietpi.com/downloads/binaries/rpi/sdl2_rpi.7z) which contain as well SDL2 mixer and net packages, probably the compile-time options and dependency libraries were based on this earlier build. However I will play around a bid.

One other question: Did you ever try to build Amiberry on x86_64? Would make general testing much easier when not always an SBC + SDcard needs to be prepared. E.g. hacking a new platform into the Makefile like:

USE_SDL2 = 1
CPPFLAGS += -D_FILE_OFFSET_BITS=64 -DUSE_SDL2 -DUSE_RENDER_THREAD -DFASTERCYCLES
midwan commented 5 years ago

@MichaIng Let me know if you need any help with compiling SDL2, we've done it so many times I could practically do it with my eyes closed nowadays. :D

Amiberry doesn't run on x86 platforms yet, as there's ARM-specific code (e.g. inline assembly) in certain areas for optimization purposes. There is a plan to make an x86 version of it eventually, but since it's a one-man-show for now, it will probably take a while. There are other things I'm trying to fix and update first. :)

MichaIng commented 5 years ago

@midwan Minimal build:

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   : mmx 3dnow sse sse2 sse3
Audio drivers   : alsa(dynamic)
Video drivers   : kmsdrm(dynamic)
Input drivers   : linuxev linuxkd
Using libsamplerate : NO
Using libudev       : YES
Using dbus          : NO
Using ime           : YES
Using ibus          : NO
Using fcitx         : NO

So with GLES:

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   : mmx 3dnow sse sse2 sse3
Audio drivers   : alsa(dynamic)
Video drivers   : kmsdrm(dynamic) opengl_es2
Input drivers   : linuxev linuxkd
Using libsamplerate : NO
Using libudev       : YES
Using dbus          : NO
Using ime           : YES
Using ibus          : NO
Using fcitx         : NO
midwan commented 5 years ago

It looks OK for a minimal build. If anything's missing, it should show right away after running Amiberry on that, in which case we could go back and re-configure/compile SDL2 accordingly. But I think it should be fine.

MichaIng commented 5 years ago

Finally only these files/links are sufficient to place into /usr/local/lib:

lrwxrwxrwx 1 root root   21 Sep 19 20:49 libSDL2-2.0.so.0 -> libSDL2-2.0.so.0.10.0
-rwxr-xr-x 1 root root 7.7M Sep 19 20:49 libSDL2-2.0.so.0.10.0
lrwxrwxrwx 1 root root   21 Sep 19 20:49 libSDL2.so -> libSDL2-2.0.so.0.10.0

Btw sorry to be a bid verbose here. I am as said compiling noob, so documenting my steps here serves as well myself at a later time 😉.

Next the image and ttf, ah probably those require the additional packages liblzma-dev and libfreetype6-dev, lets see.

midwan commented 5 years ago

No problem at all. But in order to compile Amiberry from source, you WILL need the -dev packages of those libs. :) They are not necessary to run Amiberry of course, unless you want to do an upgrade from source (with a new compile from source).

MichaIng commented 5 years ago

@midwan

But in order to compile Amiberry from source, you WILL need the -dev packages of those libs. :)

Jep, for the compilation make install installs those, the above is only what is sufficient for end user.

libsdl2-image compilation:

configure: WARNING: *** Unable to find JPEG library (http://www.ijg.org/)
configure: WARNING: JPG image loading disabled
...
configure: WARNING: *** Unable to find PNG library (http://www.libpng.org/pub/png/libpng.html)
configure: WARNING: PNG image loading disabled
...
configure: WARNING: *** Unable to find Tiff library (http://www.remotesensing.org/libtiff/)
configure: WARNING: TIF image loading disabled
...
configure: WARNING: *** Unable to find WEBP library (http://code.google.com/intl/en-US/speed/webp/index.html)
configure: WARNING: WEBP Pimage loading disabled
midwan commented 5 years ago

libpng is definitely required, as we have some PNG icons to load in the GUI. ;)

MichaIng commented 5 years ago

@midwan Okay, probably something to add to the docs then :). EDIT: Ah not, it is pulled as dependency of libfreetype6-dev https://packages.debian.org/buster/libfreetype6-dev

MichaIng commented 5 years ago

@midwan Okay SDL2 libraries compiled and ready for testing: https://dietpi.com/downloads/binaries/buster/

I finally managed to compile it on x86_64 VM by chrooting/systemd-nspawn via qemu-arm-static into an RPi respectively Asus TB image. This allows me compiling without the need to spin up or even own a related SBC and keep a build environment. QEMU does not have support for this special armv6hf that RPi1 and RPi Zero versions are, it shows armv7 there as well, but AFAIK this doesn't matter as long as all libraries and build tools are pulled from Raspbian repo, which always supports RPi1/Zero then.

One more question:

midwan commented 5 years ago

@MichaIng Regarding your questions:

MichaIng commented 5 years ago

@midwan

There's no reason not to have them as shared libs IMHO, as long as you have them compiled with all the necessary flags. If you want, you could only enable KMSDRM for example, and leave everything else to their defaults.

To keep the install slim (and as tailored for Amiberry as possible), I like to compile SDL2 with as least libraries/dependencies as possible. This also minimises future issues like the initial one with libstdio6.1/7.0 as reported originally, it allows me to remove X11 dependency from our code as well, which I find strange to have, since the idea is explicitly to run it outside of X11 and we do not even ship an X11 binary.

But this as well limits the use for SDL2 for other things, e.g. running stuff from desktop or via OpenGL etc. This is fine IMO since at least within DietPi-Software Amiberry is the only software title where we pull SDL2 for and even created the related separate SDL2 install title for, I guess. However it might cause problems if users install SDL2 via DietPi-Software for other use cases and just find it not working to start things from/within X11 session, with PulseAudio, OpenGL or other things that one usually expects. So in such case I prefer users to install the official package from Raspbian/Debian repo to avoid confusion. Our SDL2 build should then either be not shared, or if so, it should be clear that it is a KMSDRM-only +ALSA-only build, tailored for Amiberry.

midwan commented 5 years ago

Yeap, OK. Makes sense then. :)

MichaIng commented 5 years ago

First commit to remove SDL2 as separate install option: https://github.com/MichaIng/DietPi/commit/1df744cf579ccc3d48ce01afd2a90c2b00e9d6d0

However some things to do:

midwan commented 5 years ago
MichaIng commented 5 years ago

@midwan Fantastic to have this official RockChip maintained packages, which work for Stretch as well. Never saw this GitHub repo. I am wondering if/which are the differences between them and the ones from the Debian Buster repo https://packages.debian.org/buster/mali-t76x-fbdev-driver and also if the different versions (fbdev, x11, wayland) exclude each others use purpose: https://packages.debian.org/buster/libgles2 A closer look reveals that the RockChip-provided packages include libgbm => libMali symlinks, while on Debian Buster these are only provided by the wayland-specific driver package: https://packages.debian.org/buster/armhf/mali-t76x-wayland-driver/filelist This matches that those are the only ones which provide the (thus fulfil dependencies on) libgbm: https://packages.debian.org/buster/libgbm1

If those drivers indeed work well on Stretch and Buster (which can be derived from the Stretch-specific commits done), actually I tend use them throughout our Rockchip boards. The general issue is the same for all of them that on Stretch special drivers need to be found/compiled and on Buster support is limited and provided only through above linked three different packages (each chip) that seem to not support all use-cases (fbdev vs X11 vs wayland).

Our ATB image is based on the same ARMbian image btw, so kernel should be fine.

midwan commented 4 years ago

@MichaIng Not sure if this is the best place to mention this, so let me know if I should move it into a new issue?

I'm planning a code freeze for the current BETA version, and moving towards the final stage before the next stable release. Namely the sync with the various distro maintainers to ensure a smooth upgrade.

I have a list of things that you should be aware of, should I post them here or in a new issue instead?

MichaIng commented 4 years ago

@midwan New issue would be good, as I want to release v6.26 probably tonight and close all related issues.