Re: [hatari-devel] Truncated PC address value with code running in TT-RAM?

[ Thread Index | Date Index | More Archives ]

Le 30/03/2019 à 18:21, Eero Tamminen a écrit :

On 3/30/19 5:41 PM, Nicolas Pomarède wrote:
Le 30/03/2019 à 16:10, Eero Tamminen a écrit :
I will have a look ; which cpu were you using?

What one gets with "--machine falcon" i.e. 030.

As you talked about TT ram, I tested with TT mode, not falcon mode, and it seems to work. Can you check if it works in TT mode (unless the program you want to run really require falcon HW ?) As the Falcon was really supposed to be 24 biy only and TT RAM in falcon mode is a "hack", it's possible the mask is not correctly set.

I can't reproduce it with TOS, when running an Atari application that
is loaded to TT-RAM by TOS.

=> it's not a regression

It happens when Linux runs in TT-RAM, regardless of whether it's loaded
to TT-RAM by the new lilo.c code, or by an Atari application under TOS.

When Linux in TT-RAM oopses, its own backtrace shows addresses that are
in ST-RAM, although that code is actually in TT-RAM.

Maybe this issue is related to how Linux sets up MMU?

yes it could be possible that linux install its own mmu table to handle page swapping. One would need to look at the source code to check this (which I don't have time at the moment). It's quite possible that the "24 bit PC" you see will be in fact translated to a physical 32 bit address when the cpu core runs the whole MMU emulation. M68000_GetPC and other command showing regs values will in fact display logical address before translation, not the physical ones.

At least if TOS behaves correctly when using TT RAM and the PC is shown untruncated with 32 bits, then it seems the bug is not in Hatari or in the cpu core.


Mail converted by MHonArc 2.6.19+