search

aros-development-team / AROS

Main AROS repository for active development. Contains the main Operating System components and Build System.
http://www.aros.org
Other
381 stars 60 forks source link

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

Closed rvalles closed 2 years ago

rvalles commented 3 years ago

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

CPU

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.

rvalles commented 2 years ago

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.

Kalamatee commented 2 years ago

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.