|Re: [hatari-devel] Truncated PC address value with code running in TT-RAM?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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.