Tried to make ARAnyM boot a Linux-m68k kernel, but apparently the "-l" command line option mentioned in the wiki is gone? ARAnyM always seems to load EmuTOS from the default location.

Gets slightly better when supplying an initrd *cough*

Still doesn't boot to anything usable though.

Show thread

Don't you love it when a search for a phrase returns all of two results?

Apparently, it's a framebuffer problem.

Next try.

Show thread

Ohai.

ARAnyM LILO config currently is:

[LILO]
LoadToFastRam = Yes
Kernel = ~/Downloads/vmlinux-5.6.0-2-m68k
Args = root=/dev/ram load_ramdisk=1 ramdisk_size=25000 video=atafb:vga16 stram_swap=0 debug=par verbose console=tty0 debian-installer/framebuffer=false
Ramdisk = ~/Downloads/initrd.gz

Show thread

I'll have to subscribe to the debian-m68k mailing list and ask a couple of questions there - apparently the installer doesn't like something about the repository and doesn't want to download any of the remaining components (and I haven't found out how to access the virtual IDE CD from the installer initrd either).

Show thread
Follow

Hrm. The current installer can't verify keys from the archive. Checking those can be disabled with a boot parameter (see debian.org/releases/buster/amd), but setting debian-installer/allow_unauthenticated=true just leads one step further, when it sais there are no matching kernel modules.

I think I'll have to somehow aproach this differently...

(Looking at the debian-68k archives, developers are now mostly using qemu-m68k...)

@galaxis well, yes... sadly.
I always tried to argue in favour of real hardware and such. At least Adrian has 2x Amiga 060 borrowed from me, but it's really a problem: when I started with m68k autobuilders in May 2000 there were like 2200 packages or so. Now there are about 40-50000 packages to be built. That's impossible to keep up with 68060/50s
Of course it would also help when Adrian would not be more or less the last m68k dev that does the porting stuff...

@ij Tbh I was just on a detour playing around with Debian-m68k since it seemed in kind of a usable state, but I probably missed the window by half a year. Would certainly have tried on the TT if I could have made it work in Aranym.

I originally only wanted to set up a VM where I could run MiNT while I don't have access to real hardware.

@galaxis just report the issue. Adrian is usually quite quick in fixing things...

@ij @galaxis using QEMU to build packages doesn't mean some tests can't be run on real hw, right?
But they are harder to automate…

@mmu_man @galaxis Hmmm, emulated hardware is always complicated... Real hardware usually has its own bugs, maybe different from revision to revision, while emulated CPUs have different or not such bugs. So, if you compile the toolchain on an emulated system, this might work - until some corner cases will bite you on real hardware.

If everything goes back, you'll need to recompile the whole toolchain on real hardware to fix the bug.

In general, the speedup on qemu is a real benefit, though...

@mmu_man @galaxis one idea back then (like 10 years ago or so) was to use distcc in conjunction with cross-cc/qemu and real hardware. That way you could benefit from speed increases and using real hardware.
Downside would be that it's less deterministic

Sign in to participate in the conversation
INFRa Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!