Re: [hatari-devel] ASV unix crash with TT emulation

[Markus Fröschle <markus@xxxxxxx>]

It might well be that this is the case but actually, this hasn't much to do with the second MFP anymore (other than that the missing interrupt is supposed to arrive there, eventually).

Its more about the missing RTC interrupt itself that needs to be triggered first. Otherwise ASV will not boot that far anyway.

One hurdle at a time only.

Am Samstag, dem 13.03..2021 um 19:36 +0200 schrieb Eero Tamminen:

Hi,

Second MFP isn't only potential problem.

Did you verify with "--trace vme" that ASV

doesn't try to use TT VME/SCU registers?

E.g. Linux doesn't boot with Hatari TT

emulation unless VME/SCU access is disabled

(with "--vme none") as Linux will try to use

SCU regs if they appear to be present.

(I added support for tracing & disabling Hatari's

no-op VME/SCU reg access after v2.3.1 release, so

Hatari git version is needed for this.)

        - Eero

On 12.3.2021 11.29, Markus Fröschle wrote:

bringing up this old issue again.

I have had a look into it and it appears that the ASV Unix crash dump

is misleading here. Using the Hatari debugger,I tried to find out what

happens here.

Indeed it appears to indicate the MFP involved in the crash, but

actually, this seems to be a subsequent fault(as it shows the registers

from the crashdump writeout itself that is not only written to the

screen but to theserial port as well).

The root cause of the crash appears to be indeed this:

WARN : Write to unimplemented RTC/NVRAM interrupt enable bits 0x40

ASV seems to be using the TT RTC's timer interrupt as kind of watchdog

and crashes if this does not trigger as expected.

Not sure if this is the only issue that prevents ASV from booting, but

at least I would really like to give it a try.

Question is: what would it take to properly implement this interrupt?

Can somebody provide pointers on where to look

best for a sample implementation of an interrupt trigger in Hatari's

source code that could be used as a template?

I already peeked into the source tree but admitted, I'm a bit lost on

where to start. Hints appreciated.

Thank you!

Am Montag, den 06.05.2019, 18:18 +0200 schrieb Nicolas Pomarède:

Le 06/05/2019 à 18:02, Uwe Seimet a écrit :

Hi,

Interesting news. I just checked the behavior of ASV, which appears

to get abit further in the boot process now. There is an exception,

though, pleasesee the attached screenshot.

Hi

hard to tell what went wrong with this screenshot (and I don't know

ASV that much) ; strange thing is that A0=FFFFFA13 in that dump,

which would mean it was an access to main MFP whose behaviour was not

modified (hopefully). But it's not sure the faulty access was made on

this address, one would need to see the corresponding asm code.

Nicolas