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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 3/30/19 7:46 PM, Thorsten Otto wrote:
> On Samstag, 30. März 2019 18:33:03 CET Nicolas Pomarède wrote:
>
> > yes it could be possible that linux install its own mmu table to handle
> > page swapping
>
> Yes, definitely. Not only for page swapping, but every process gets the same
> virtual address space, regardless where it is located physically in RAM. This
> is different from current Mint behaviour for example, where the MMU is only
> used for protection, but there is a 1-to-1 mapping for addresses.
>
> > then it seems the bug is not in Hatari or in
> > the cpu core.
>
> Maybe not in the CPU core, but apparently in the disassembler, using the
> functions that use physical addresses to fetch opcodes. When the MMU  is
> active, you need to translate them first (it is not just adding the memory
> bank offset, you really have to go through the MMU table).
>
> I'm not sure how Hatari handles this currently, but in Aranym there are
> functions like phys_get_long(), mmu_get_long() etc. for this purpose.

Btw. In case somebody wants to take a look, I uploaded everything
(m68k-linux kernel v5, its symbols, small rootfs and lilo.cfg)
needed for testing here:
http://eerott.mbnet.fi/hatari/packages/m68k-linux-v5.tar.gz  (3MB)

Just extract it and run Hatari with something like this:
hatari --natfeats yes --machine falcon --dsp dummy --mmu on --fpu 68882 
-s 14 --ttram 64 --addr24 off --ide-master bb-rootfs.img -c lilo.cfg 
--lilo "init=/init"

Note: If you're not interested about kernel symbols, leave "Symbols"
setting in lilo.cfg empty, or comment it out, as loading it outputs
a lot of messages to console (due to large number of overlapping
symbol names & addresses in the symbols file).


	- Eero