Re: [hatari-devel] SCU/VME register access?

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Mon, 10 Jun 2024 23:04:05 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 07/06/2024 à 14:51, Eero Tamminen a écrit :
> > Hi,
> > 
> > On 5.6.2024 12.46, Nicolas Pomarède wrote:  
> >> 4 years later, time to resurrect this old thread :)
> >>
> >> Are there any ready to use linux disk image I could use to check the 
> >> boot process regarding SCU registers ?  
> > 
> > If you're using Debian, it's easy to build latest m68k Linux kernel.
> > 
> > Just copy-paste the commands given in the "3. Building m68k kernel" 
> > section of the Hatari "m68k-linux.txt" doc (with "/path/to/hatari" parts 
> > replaced by path to your Hatari checkout).
> > 
> > If you do not have Debian, I can mail you the kernel and its symbols 
> > file (about 5MB uncompressed).
> > 
> > 
> > Example in "6. Running Hatari" section tells how to run that Linux 
> > kernel with Hatari.
> > 
> > As TT SCU is accessed already at Linux boot, you do not need a disk 
> > image i.e. you can drop the "--ide-master" option (besides replacing 
> > "falcon" with "tt"). [1]
> > 
> >   
> >> I know there's also the SysV disk images at http://www.atariunix.com/ 
> >> but it seems they also rely on the RTC's internal timer interrupt, 
> >> which is not emulated so far
> >>
> >> Or some other programs that modify SCU registers ? (apart from the TOS 
> >> used in MegaSTE / TT)  
> > 
> > This is shown by "--trace vme" on latest m68k Linux v6.9:
> > ---------------------------------------------------
> > ...
> > VME: SCU read  (0xff8e01): 0x00
> > ...
> > NR_IRQS: 141
> > VME: SCU write (0xff8e01): 0x10 (system interrupt mask)
> > VME: SCU write (0xff8e0d): 0x60 (VME interrupt mask)
> > clocksource: mfp: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 
> > 77769386670404 ns
> > unexpected interrupt from 112
> > Console: colour dummy device 80x25
> > printk: legacy console [tty0] enabled
> > unexpected interrupt from 112
> > ...
> > unexpected interrupt from 104
> > ...
> > ---------------------------------------------------
> > 
> > (After which there are constant messages of both 104 & 112 interrupts.)
> > 
> > 
> > Whereas with "--vme off", linux boots to user-space just fine under TT 
> > emulation.
> > 
> > 
> >      - Eero
> > 
> > [1] Section "4. Building root file system" gives commands for building 
> > two different root file systems from packages available on Debian, one 
> > based one Busybox, and another based on klibc utilities.
> > 
> >   
> 
> Hi
> 
> using the linux image you sent me, I ran hatari with :
> 
> hatari  --machine tt --tos tos306fr.img --dsp off --fpu 68882 --mmu on 
> -s 14 --ttram 64 --addr24 off -c lilo.cfg --lilo "debug=nfcon 
> root=/dev/ram ro init=/init" --trace vme
> 
> then I see (this is a work in progress version with SCU support)
> 
> scu write sys_int mask ff8e01=0x10 pc=3aa022
> scu write vme_int mask ff8e0d=0x60 pc=3aa028
> 
> writing 0x10 at ff8e01 allows vsync interrupt (but not hsync), but then 
> the linux boot shows lots of line "unexpected interrupt from 112". And 
> 112 is 0x70, which is VBL interrupt.
> 
> so it's strange that linux allows vsync interrupt but then shows some 
> errors about interrupt 112 (and in the source code at 
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/atari/ataints.c#n304 
> it says vbl is enabled for the cursor)

Just a blind guess, but is there maybe something wrong with the VBR
emulation in Hatari?

Linux sets up the table to a different location in RAM:

 https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/kernel/vectors.c#n61

 Thomas