aros-development-team/AROS

amiga-m68k-boot-floppy from 2021-04-01 nightly crashes on A500

rvalles opened this issue · 2 comments

Describe the bug
amiga-m68k-boot-floppy softkicking fails, crashing the Amiga.

To Reproduce
Steps to reproduce the behavior:

  1. Write amiga-m68k-boot-floppy's adf into a floppy (I used amigaXfer for this, with verify set to read)
  2. Boot it

Expected behaviour
AROS softkicks properly.

Screenshots
image

Architecture

  • Amiga

CPU

  • m68k

Version
2021-04-01 nightly build.

Additional context
Amiga is a PAL rev6 A500.
Kickstart ROM is 34.5 (standard 1.3 A500 rom)
CPU is 68010 (on standard CPU socket, so 7MHz).
Fat Agnus 1MB / ECS Denise.
1MB chip + 1.5MB slow at $C00000.
Booted from DF0. A Gotek with FlashFloppy is present as DF1.

Seeing bug closed w/o explanation, I gave the nightly a try. I used an emulated Amiga (winuae on wine) of the same configuration as I can't (right now) test the hardware.

It works now. But it does notably take a very long time (several minutes) to load the kickstart, during which the whole floppy is read several times in a row.

Therefore, something or another is far from ideal. My guess is that it's due to aros.hunk being gzipped, then random access exercised on it.

Hi @rvalles,

You are correct - I have closed the issue because it is now resolved partially. AmigaOS should now boot AROS using AROSBootstrap again, and a ticket has been opened for the underlying reason for the failure.

As for the slow boot - it is because currently the .gz is based upon the elf of the rom, rather than the hunk version of the file. While not ideal, it does allow it to continue working until the underlying problem is addressed.

FWIW - The actual failure is due to the gnu tools producing a 32bit PC relative relocation in the generated m68k elfs, which Elf2Hunk tried to store using a 16bit hunk relocation (RELRELOC32). Obviously, this cannot work for all relocations.