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